On 20/05/2010 18:30, Russ Allbery wrote:
Roger Leigh<rle...@codelibre.net> writes:
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)
You can't move the static reserved space: it contains statically assigned
UIDs. :) That's the whole point of it. We could change where we're
assigning future static UIDs and GIDs from, but I'm not sure it's worth
the effort given that there's always going to have to be a legacy reserved
space for the ones that were already assigned.
Do we have any actual users of this space? I didn't see anything in
Policy. Is there a central database listing the assignments? If so,
where may it be found?
In the absence of any existing static assignments, I don't see any
issue with moving the range. If there are assignments, could these
not be moved for new installs?
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.
I don't think it's a good idea to let people assign 65535 to a regular
user. That's been hardcoded as nobody in a vast number of UNIX systems
for decades. Reusing that UID for other purposes in any sort of shared
infrastructure is almost certain to cause problems.
65534 is the UID for nobody. Anything using the UID for nobody should
be getting it through the libc functions as for any other user; does any
code actually hardcode 65534? IMO that's a bug if so. Given that
nobody can't create files except for in /tmp and other world-writable
locations, there shouldn't be any issues with changing the UID/GID since
nothing in the filesystem should be owned by them. A quick check on my
system shows just two locations:
drwxrwxrwt 2 nobody nogroup 4096 Jan 27 2009 /var/spool/cups-pdf/ANONYMOUS
drwxr-se-x root nogroup 63488 May 2 01:04 /usr/lib/kde4/libexec/kdesud
The first is totally pointless (bug filed), it could just be root:root
and be even more safe. The latter looks OK but should we really be
having a file owned by nogroup in the filesystem at all on general
principle?
Regarding 65535: Does any software actually hardcode the number 65535?
Given that its only use is as an error return (-1) for uid_t and this is
now a uint32_t any code hardcoding this value is already broken.
The main justification I would have for this change is that keeping the
old 16-bit-constrained assignments fragments the 32-bit range space
unnecessarily. For checks such as being discussed, having a contiguous
user range makes things much simpler for both us and admins. I accept
that we can't change things for existing systems where these are already
being used, but it sucks to be stuck with a 16-bit legacy for evermore
even for new installs.
Regards,
Roger
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bf58e18.3030...@codelibre.net
