Robert Connolly wrote: > On Monday March 26 2007 01:11, Bruce Dubbs wrote: >> The use of 65534 for a uid or gid is not a good idea. It comes from old >> time usage in nfs and nowhere else. *If* nfs does not find a nobody >> user, it defaults to -2. Since the uid/gid are 16 bit numbers, this >> equates to 65534. There are two things wrong with this. First it makes >> the /var/log/wtmp look very large when viewing with ls -l. du >> /var/log/wtmp does show the correct disk usage though as it is a sparse >> file but the ls -l can confuse users that don't know its a sparse file >> (or even what a sparse file is). If the file system does not support >> sparse files, the file really is huge. > > I thought it had more to do with 65534 being the last available 16-bit ID > (even though Linux handles 32-bit ID's). The last available ID is generally > thought of as the least privileged user, although technically it is not. > >> I think most modern distros use 99 for nobody as we do. I know RedHat >> does at least as far back as RH9. They do have a nfsnobody user, but >> that is merely for an ls -l display if accessing a disk with very old >> practices. > > Using 99 works, but I think 65534 is more widely understood as the 'nobody' > ID... in that if you see a uid 65534 in a tar archive you automatically know > it once belonged to 'nobody'. A group ID of 65533 would be easy to assume as > a close relative of 'nobody', such as 'nogroup'. > > There are probably uses for this assumption, but the only one I can think of > is when unpacking binary tarballs with programs like 'kdesud' which are 'sgid > nogroup'.
I don't think so. The tar file only knows uids and gids, not users. Some systems use nogroup, some use nobody (in /etc/group). > Using these large and old fashioned ID numbers is logical to me, even though > there's no technical merit to it. > > I could see ID 99 becoming understood as 'nobody', but currently I don't > think > it is (in the scope of the *nix community). One of the reasons for LFS and BLFS is to explain what is gong on. If there is no technical merit to it and there are reasons against it, then "we have always done it that way" is insufficient. We already explain it in http://www.linuxfromscratch.org/blfs/view/cvs/postlfs/users.html http://www.linuxfromscratch.org/blfs/view/cvs/server/nfs-utils.html#nfs-utils-install >> Secondly, if a user is able to log in somehow and the home directory >> does not exist, it defaults to /. You see this if a home directory is >> on a separate partition that is not mounted. This is why root's home >> directory is always /root and not /home/root. >> >> I highly recommend using /dev/null instead of /nonexistent. > > Using /nonexistant is usefull if you set 'DEFAULT_HOME no' in > /etc/login.defs. > Using /dev/null would also work with the DEFAULT_HOME setting because it's > not a directory. I don't see either one having an advantage over the other, > except that one exists and the other does not... and considering > what /dev/null is, it leaves a gray area of difference. *If* /etc/login.defs is modified, then it doesn't make any difference. If it is not changed from the default, then /dev/null is preferable. In fact, is probably a mistake to change /etc/login.defs if a user's directory is not on the / partition. It would depend upon the knowledge level of the user and the permissions given. Also, is login.defs used if you have pam installed? I'm not sure. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
