On Thu, May 20, 2010 at 02:34:30PM +0200, Santiago Vila wrote: > On Thu, 20 May 2010, Raphael Hertzog wrote: > > > Hi, > > > > On Thu, 20 May 2010, Santiago Vila wrote: > > > So I agree that the sane thing to do here is, at least, to use the > > > same default range as /etc/adduser.conf (which in turn is the range > > > defined by policy). > > > > > > I've just modified base-files accordingly to use the UID range 1000-29999. > > > > I'm not sure this makes lots of sense. > > > > hertzog@alioth:~$ id -u maximilinux-guest > > 220227 > > > > There are many installations out there with large numbers of users that > > simply can't respect the ranges set by the policy. > > > > I would simply use a minimum of 500 or 1000 to differentiate system users > > from normal users. adduser is not a required step to create accounts when > > you manage your account database in LDAP/PostgreSQL (or whatever else). > > > > Having a different behaviour betweent accounts simply because some are > > above the maximal limits and some are below would be counter productive. > > > > The policy was written when uid/gid were only 16 bits but our systems cope > > with greater number of users nowadays... maybe the policy should be > > revised on that point. > > Yes, maybe we should modify policy. > > But for now, current policy says UIDs over 30000 are "reserved", which means > they might or might not be "ordinary user accounts". > > Those who do not use "adduser" because "they know that they are doing" > will surely be able to change /etc/profile if the default one is not > suitable for them, as it happens with every default value in the system. > > If we don't follow policy closely here, we can't claim that the umask > change does only affect "ordinary user accounts" (which is what I > think the release notes for squeeze will say). > > So, I'm just providing a default which is consistent with other > defaults in the system and also with policy. I think using the user range defined by policy is fine for now. At worst, sites using the "reserved" and "reserved for Debian" ranges will get an 0022 umask for user accounts in this range until they change the user range, i.e. no decrease in security. > If by doing so we realize as a result that policy should be modified, > let us modify policy then. If all current Debian systems support a 32-bit UID and GID range, then it would be great if we could amend Policy to move the reserved ranges to the end of the 32-bit range rather than being at the end of the 16-bit range. This would give a vast contiguous user range (4294931294 UIDs using the scheme below) Likewise, 65535 is no longer a prohibited value; it's now (2^32)-1 = 4294967295, so Policy could also amend this restriction. Additionally, user nobody would then be in the middle of the user range; it could be shifted back to the end of the 32-bit range. Suggestion for Policy: 0-99: Debian Global 100-999: Debian Dynamic 1000-4294932293: Users [65534: nobody; could be moved to 4294967294 for new installs?] 4294932294-4294962293: Reserved 4294962294-4294967293: Debian Static Reserved 4294967294: nobody [new] 4294967295: (uid_t)(-1) == (gid_t)(-1) must not be used, because it is the error return sentinel value. The ranges can be adjusted to make them tider if desired; this is just adjusting the ranges as above, and drops the final (tiny) reserved range. For example: 4294900000-4294969999: Reserved (60000, was 30534) 4294960000-4294967293: Debian Static Reserved (7293, was 5000) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Attachment:
signature.asc
Description: Digital signature