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

Re: UPG and the default umask

On 20/05/2010 18:30, Russ Allbery wrote:
Roger Leigh<rleigh@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.


Reply to: