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
>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.
Does it will break reading file from uid16 filesystem?
Regards
Bastien
>
>Regards,
>Roger
>
>
>--
>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: