Re: New!!!: Base-passwd 2.0
Philippe Troin:
> I'm about to upload a drastically modified version of base-passwd.
> The new feature is automatic upgrade of passwd and group entries.
Great. I think I have some ideas how to solve this problem - please
excuse me if this proposal has been discussed before. I think the whole
process needs to be decentralized somewhat. How about the following:
- base installs only a minimal /etc/passwd which will not change
- we have a separately maintained list of allocated system UIDs
- packages that need these users add them automatically when installed
and delete them when purged
Packages that have specific UIDs compiled in (like qmail, for performance
reasons - this should be avoided whenever possible though) create the
users with these centrally allocated UIDs (using the -u uid useradd flag;
duplicate UIDs won't be created unless -o is also given).
Not all packages need a specific UID - just a new username (they look up
the UID at run time). UIDs for such users can be allocated when the user
is created by the useradd command. In any case, useradd always checks for
duplicate usernames (simply not allowed, unlike duplicate UIDs).
If a new user is created, the package is also responsible for creating any
mail aliases if necessary (otherwise, mail sent to any system user will end
up in /var/spool/mail/<username> and that's not always desirable - too easy
to fill up the mail spool without anyone noticing).
The /etc/passwd file only contains system users needed by packages that
are currently installed. It is less likely that system users are left
without mail aliases. There is no need to upgrade the default /etc/passwd
ever again.
The current scheme (put system users needed by every package in the default
/etc/passwd) was developed before the tools to non-interactively add and
delete users were available (the only way was to edit /etc/passwd). Now
that we have these tools, I think we should take advantage of them.
Comments?
> What happens if an entry exists in passwd which is not in shadow ?
The non-shadow password is used instead. Next time you run pwconv5,
encrypted passwords in such entries are moved to the shadow file.
> => I assume that the user cannot log in, which is perfect for
> daemons.
If the non-shadow password is * or the like, the user cannot log in.
> 5) How do you perform passwd and group locking ?
That needs more discussion. The standard way to do it (as specified by
SVID 3) is to use lckpwdf() and ulckpwdf() - available in libc-5.3.5 and
newer (and in recent versions of glibc, too). These functions use POSIX
(fcntl) locks on the file /etc/.pwd.lock (never removed once created).
Unfortunately, only very few programs do it this way now (the pam_unix
module is one example). The shadow suite uses its own locking mechanism
(which works much like uucp lock files - create a new file with the pid
of the lock owner, and use link() to switch it into place). There are
plans to use lckpwdf() instead, if available.
Some other programs use /etc/ptmp, but this has some problems - if the
process dies without removing the file, it has to be removed by hand.
This problem doesn't exist with lckpwdf() (locks removed by the kernel
when the process exits) and with the shadow suite (invalid locks are
removed automatically if the lock owner no longer exists during the next
locking attempt). Also, last time I looked at adduser, it checked for
/etc/ptmp and then created it (leaving a race condition).
That said, even commercial systems have problems with password file
locking: I know that at least on HP-UX 10.01, vipw uses /etc/ptmp and
useradd uses lckpwdf(). So, useradd will happily add a new user while
you are using vipw. The new user will disappear when you save changes.
We really should do better than that, but it's not _that_ urgent...
Marek
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: