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

Re: UPG and the default umask

"Roger Leigh" <rleigh@codelibre.net> a écrit :

>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 
>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.

Does it will break reading file from uid16 filesystem?


>To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
>with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>Archive: [🔎] 4BF58E18.3030708@codelibre.net">http://lists.debian.org/[🔎] 4BF58E18.3030708@codelibre.net

Reply to: