[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 is in fact a leading question. With version 3.0, Samba adds increased support for foreign SIDs -- that is, NT-style uids and gids corresponding to remote NT domains -- which nevertheless need to be mapped to ids on the local system to be useful. This is normally handled by allocating a pool of uids and gids on the Unix system for use by "idmap". I believe it would be of benefit to many Debian users of the samba packages if the default configuration included a reasonable pool of uids and gids for this purpose. 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. ;) 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; even something as small as 5000 uids should be ok, since admins always have the option of choosing a different range -- it's just a question of how useful the defaults will be to our users. -- Steve Langasek postmodern programmer
pgpRX8uUOsGZG.pgp
Description: PGP signature
