Re: UPG and the default umask
Roger Leigh <rleigh@codelibre.net> writes:
> On 20/05/2010 18:30, Russ Allbery wrote:
>> 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?
Steve got this part.
>>> 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.
Sorry, I meant 66534. You're of course correct with 66535; you can't use
that on 16-bit UID systems, but otherwise it shouldn't be as much of an
issue.
> 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.
Different sort of hard-code. It's in tons of existing /etc/passwd files,
and giving another user the same UID as nobody (such as, for instance, a
mix of LDAP and local /etc/passwd data stores) can produce some nasty
security exposures depending on how nobody is being used.
> 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.
By default, assuming use only of packages in Debian and no changes by
local administrators. Those aren't good assumptions.
Changing a UID is a very big and disruptive change, and remember that a
lot of sites share UIDs site-wide.
> 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 agree with Steve: the best way to provide a contiguous range is to start
in 32-bit space above our existing reservations.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: