On Thu, Jul 03, 2003 at 09:58:12AM +0100, Colin Watson wrote: > 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? On my last remaining 2.2 machine, with glibc 2.1.2, userspace uid_t is 32 bit and attempting to call chown() with a value in excess of 2^16 results in it being silently truncated. I'm not sure what the behavior of glibc 2.2 is in this regard; if no one else is in a position to check, I'll see what I can find out. > (from /usr/share/doc/base-passwd/README) Ah, good to know, thanks. > > 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 think that for listing which ones have in fact been registered by packages, base-passwd is fine; but I definitely feel that this general sort of usage needs to first be authorized (and documented) in 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. This seems reasonable. I have a good idea how to open a dialog with the LSB folks about this, but how would we go about getting input specifically from large installations that have already broken the 2^16 barrier? -- Steve Langasek postmodern programmer
Attachment:
pgpeB0VDlwInd.pgp
Description: PGP signature