[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Policy for 32-bit uids/gids?

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


Colin Watson                                  [cjwatson@flatline.org.uk]

Reply to: