On Wed, Jul 02, 2003 at 01:15:09PM -0500, Steve Langasek wrote:
> [Re-sent due to inability to properly address email.]
>
> Section 10.2 of policy currently describes uid and gid classes covering
> the range of 0-65535. This appears to no longer be comprehensive: on a
> current system running a 2.4.18 kernel and libc6 2.3.1-17, I'm able to
> assign 32-bit userids to accounts and reference these accounts in file
> ownerships, su to them, etc. Should Debian Policy be expanded to
> address this greatly increased range of available ids?
This, together with your specific Samba proposal, sounds like a good
idea, provided that the failures experienced by people with older
kernels will be graceful and reasonably self-explanatory. Is anyone in a
position to test this?
> When I say "reasonable" here, I do mean "able to accomodate the ACL
> needs of a moderate-sized corporate WAN": the 60000-64999 range
> /might/ be sufficient, if Debian were willing to allocate the whole
> thing to Samba. ;)
You can't have all of it anyway. :)
Reserved uids:
uid | name | description
------+-----------+---------------
63434 | netplan | netplan
64000 | ftn | fidogate
64001 | mysql | mysql-server
64005 | tac-plus | tac-plus user
64010 | alias | qmail alias
64011 | qmaild | qmail daemon
64012 | qmails | qmail send
64013 | qmailr | qmail remove
64015 | qmailq | qmail queue
64016 | qmaill | qmail log
64017 | qmailp | qmail pw
64020 | asterisk | asterisk
Reserved gids:
gid | name | description
------+-----------+---------------
63434 | netplan | netplan
64000 | ftn | fidogate
64001 | mysql | mysql-server
64005 | tac-plus | tac-plus group
64010 | qmail | qmail
64020 | asterisk | asterisk
(from /usr/share/doc/base-passwd/README)
> However, with the recent availability of 32-bit uids, this seems
> unnecessary. I would suggest allocating a 16-bit range out of the
> remaining (2^32-2^16) uids for Samba's use, and the same for gids;
Provisionally, seems sensible. Should base-passwd be the registry for
any similar high allocations in the future, or policy?
I'm slightly concerned by how we're going to map onto other systems'
uses of 32-bit uids here, since there will already be some. 0-99 and
60000-64999 were reasonably obvious back in the day, but I don't have a
feel for how big systems are allocating uids now. I would be inclined to
start allocating from near the top, although perhaps not right at the
top to avoid 2^32-1. Perhaps we should reserve something like 2^32-2^24
to 2^32-2^16 (255 chunks) so that we have space for anything else that
may turn out to need similar large block allocations.
I would like to see an initiative to agree this between multiple
distributions via the LSB or similar with input from people running
large systems, otherwise there'll probably be a horrible mess down the
line.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
