Re: New!!!: Base-passwd 2.0
On Wed, 22 Jan 1997 03:21:37 +0100 Marek Michalkiewicz
(marekm@i17linuxb.ists.pwr.wroc.pl) wrote:
> 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:
Well, there was a discussion a while ago about this...
> - base installs only a minimal /etc/passwd which will not change
We'll have to change it. Previously, you had to it it by hand. What
2.0 (when released) brings is autmated updates.
> - 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
This might not be the more appropriate... Some UID correspond to no
packages at all (cdrom, sound, etc...) and some new ones can be
added, or the old ones removed/changed.
> 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).
I think we want to avoid to many changes in the sources from the
upstream distribution. Using getpwbynam() should be suggested to the
upstream maintainers, but for the packages which don't use it, we
have to provide a way...
> 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).
This is a really good idea. I will incorporate it into the
update-passwd script.
> 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.
As stated before, this won't do for every case.
> > 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.
Thanks for the info.
> > 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.
What do the maintainers for login, shadow, xdm adduser, etc... think
about it ?
Is there a debian standard way of doing this ???
Phil.
--
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: