[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bits from the release team: the plans for etch



On Wed, Oct 26, 2005 at 08:18:42AM +0200, Marc Haber wrote:
> On Tue, 25 Oct 2005 22:21:18 +0200, Javier Fernández-Sanguino Peña
> <jfs@computer.org> wrote:
> >Creating system users needs to cope with the fact that users might have
> >greated them before hand.
> 
> adduser copes with that. If a system user to be created does already
> exist with the required properties, adduser is a no-op and exists with
> a zero exit code. If a system user to be created does already exist
> with different attributes, it exists with non-zero exit code, as this
> is an error.

And that's something that packages maintainer scripts have to cope with since
they don't know beforehand if it's there and it certainly doe snot have the
same attirbutes (it might only share the name)

> Thus, in most cases, a single call to adduser is all that's needed to
> create a system user in postinst.
 
I have yet to see a package that "just" calls adduser. Some remove the user
(and fail to check if it was created by the postinst/preinst and not by the
alocal admin), some set additional groups, setup its home directory (uneless
defined with dpkg-statoverride already). I can provide you a script to show
you all the postinst/preinst/postrm of packages that create a user on
installation.  You can see for yourself.


> Your code, otoh, will overwrite local configuration which is an RC
> bug.

Please explain, the code only changes /etc/{passwd,shadow,group}. Where's the
RC bug?

> > There's some code that needs to be written to cope
> >with different packaging situations that adduser is unable to
> >contemplate by itself.
> 
> Which situations?

For example:

- Creating the user's homedir and assigning proper permissions if (and only
if) the admin has not overriden it with dpkg-statoverride
- Adding the user to additional groups if required

> 
> >Not including the fact that the user created by a
> >package might need to be removed on postinst.
> 
> Removing system users on package purge is widely regarded a bug since
> one cannot guarantee that the local admin hasn't used the account for
> other things as well. Additionally, removing the system user on
> package purge might leave orphaned files around. If the maintainer
> decides to remove a user in postinst, that can be done with an
> explicit deluser call.

That really depends on the daemon itself don't you think? There's a number of
daemons that don't create any file at all or, if they do, are created
only on a given directory which is removed on purge. In these cases, removing
the user on postrm's purge might make sense. As I said, that would be an
option. 

> Frankly, I do not see any advantage in your dh_user idea.

Quite frankly, I do.

Javier

[1] Those are just some of the ones doing this. Full list:
lynx -nolist -dump
$ http://lintian.debian.org/reports/Tmaintainer-script-needs-depends-on-adduser.html |perl -ne 'print $1."\n" if /W: (.*?): /
$ grep-available -sPackage -FPre-Depends,Depends adduser | awk '{print $2}'

Attachment: signature.asc
Description: Digital signature


Reply to: