Re: New!!!: Base-passwd 2.0
On Thu, 23 Jan 1997 02:03:37 +0100 Marek Michalkiewicz
(marekm@i17linuxb.ists.pwr.wroc.pl) wrote:
> Philippe Troin:
> > > - 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.
>
> Oops, I forgot that a few UIDs and GIDs don't correspond to any package
> at all. These need to be handled like you are proposing. But I still
> think it would be nice to have packages manage the UIDs/GIDs they need
> when installed/purged. This way, base-passwd will not change often,
> pwck won't complain about missing home directories (like /var/qmail if
> qmail is not installed), and packages don't need to depend on specific
> versions of base-passwd (if previous versions didn't provide necessary
> users/groups).
Agreed.
> > > 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...
>
> Yes, but the statically allocated UID doesn't need to be in base-passwd
> - it can be managed by the package itself.
Yes... but... This can be problematic. Let's say that we allocate the
`news' entries dynamically... Then you install two news servers (why
not ?), both needing the news uid.
When installing the server #1, it creates the entries. Installing the
server #2 tries to create the entries, but fails (ok so far). The
problem is that when you will remove one of the server, it will have
to check that some other package needs to keep the entry so that it
doesn't remove it.
A kind of database of programs using some passwd entries could be
part of base-passwd. Then the package wouldn't call adduser and
deluser directly, but this special program.
Ok I have to modifications to do...
> OK, but it's still good for most cases. Let's have the best of both worlds:
> packages manage users/groups they need (centrally allocated if fixed IDs are
> necessary), base-passwd manages users/groups that don't correspond to any
> package at all.
I'll try to find out in my archives the old passwd resolution and
update it and submit it for comments...
> [passwd file locking]
>
> > What do the maintainers for login, shadow, xdm adduser, etc... think
> > about it ?
>
> Not all packages listed above need to know anything about passwd file
> locking. Since password files are updated by using rename() to switch
> the new file into place (it's safer that way), programs that have the
> file open for reading will continue to read the old file. Locking is
> only necessary for a few programs that _update_ the passwd files. This
> leaves (besides base-passwd) just adduser, passwd, shadow-passwd.
You make a very good point about the rename() stuff. Then, only adduser and the automatic updater (aka base-passwd) would have to implement the lock. And programs reading the passwd files wouldn't be bothered at all !!!
[See also my answer to Lars's posting]
Thanks for your constructive input !!!
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: