Re: New!!!: Base-passwd 2.0
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).
> > 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. Most packages, that don't
use compiled in UIDs, don't even need anything allocated in the (small)
1-99 range - simply allocate any random free UID during installation
(unless it needs to be consistent across different machines - but this is
a local issue, so just ask the user for specific free UID to use instead
of "highest existing UID + 1").
> > 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.
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.
[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.
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: