Re: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package
>From: Chris Lawrence <lawrencc@debian.org>
>On Feb 19, Wichert Akkerman wrote:
>> Previously Chris Lawrence wrote:
>> > Will do. The uid/gid 1 issue is definitely an issue; Debian probably
>> > can't make that change, and I suspect many other LSB implementations
>> > would trip over it too if they have any POSIX already.
>>
>> We can just drop most of the standard accounts and become compatible
>> by simply not having an optional account. Most of bin/daemon/sync/etc.
>> aren't used anyway it seems.
>Unfortunately, the following accounts are required (per
>http://www.linuxbase.org/spec/refspecs/LSB_1.1.0/gLSB/usernames.html):
>USER GROUP UID GID
>root root 0 0
>bin bin 1 1
>daemon daemon X X
>X = unspecified
Daemon has always been 1 on all traditional UNIX versions including AT&T
and *BSD. The real problem between AT&T and *BSD was that
AT&T uses 2 for bin and 3 for sys
while
*BSD used 3 for bin and 2 for sys.
Also note that on SunOS 3.x and 4.x "nonody"/"nogroup" have been 65534 \**
while SunOS 5.x and SYSvr4 defines "nonody"/"nogroup" to be 60001
and in addition introduce "noaccess" with 60002.
**) BSD seems to have copied over the old SunOS nobody mapping.
NOTE: If you ever plan to share e.g. /usr via NFS in order to have e.g
discless or dataless clients you need to aggree on a static map for
all system relevant IDs.
Also note: if you like to use a recent TAR standard format \**
for data exchange there is a need to standardize nobody/nogroup for security
reasons. If you don't standardize nobody/nogroup, you need at least
forbid 65534 & 60001/60002 for regular users.
Note that many people run file servers with a passwd file that does not
hold uid information for the users on the NFS clients. It you make backups,
there then is only numeric ID information. As you must take care people who use
outdated TAR implementations (like the "pax" implementaion recommended by
Mr. Kukuck from SuSE), keep in mind that those implementations do not support
POSIX.1-2001 extended headers like "star" and thus will not understand them.
They will only see the 7x3 bit values from the old TAR header. For this reason
it is important that in case you are archiving ID values > 2097151 you need to
use the value of "nobody" for the small number in the old TAR header.
If you don't, you will end up to see the real ID modulo 2097151 which may be a
real secority problem in case the files have TSUID or TSGID bit set in the
permissions.
OK, let me stop here and see if there is the right audience on this group
before I probably waste my time while writing mail....
**) It seems that at least Mr. Kukuck from SuSE decided to use a "pax"
implementation which only supports the 1990 POSIX standard, so there cannot be
Large File support or support for UID/GID > 2097151 on LSB Linux.
>On Debian:
>USER GROUP UID GID
>root root 0 0
>bin bin 2 2
>daemon daemon 1 1
This is funny and not somilar to any traditional UNIX system - why?
Jörg
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.gmd.de (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
Reply to: