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

Re: Bug#621833: System users: removing them

This one time, at band camp, Roger Leigh said:
> On Sun, May 29, 2011 at 12:09:40PM -0500, Jonathan Nieder wrote:
> > (culled cc list of a few people I know read -devel)
> > Roger Leigh wrote:
> > 
> > > Given the need to consider unlocking as well as locking, I'm not sure
> > > it's worth adding special support to deluser: the typical logic used
> > > to create the user will be insufficient to unlock, so it's no less
> > > the effort to add an explict unlock/lock to the maintainer scripts,
> > > dropping use of deluser entirely.
> > 
> > The obvious question then would be whether it's worth adding special
> > support to deluser *and* adduser, no?
> We could add special behaviour to adduser to unlock the account
> if it already exists when run in the postinst.  However, most
> postinsts wrap the call to adduser with a check for whether the
> account already exists, so it would not be called without an
> update to every preinst employing this strategy.  It would also
> alter the existing behaviour of adduser, which is to return nonzero
> if the user already exists, which could cause breakage.

I know that people do that, but it is unnecessary scaffolding.  adduser
already handles that just fine.  Maybe the documentation is lacking, but
the design goal is that you can just call adduser --system --quiet $args
in your postinst, and adduser will do what you meant:

steve@varinia:~$ getent passwd postfix
steve@varinia:~$ sudo adduser --system --quiet postfix
[sudo] password for steve: 
steve@varinia:~$ echo $?

adduser does return non-zero for non-system accounts that already exist,
but it purposefully does it this way for system accounts to be more
friendly to maintainer scripts.

> I dislike the fact that the behaviour of adduser and deluser would,
> in effect, /not/ add or delete users as intended, which is rather
> counter-intuitive.  Providing that we have consensus on a recommended
> strategy for locking and unlocking accounts which can go into policy,
> I think all we need are examples for how maintainer scripts are
> expected to handle account creation and locking/unlocking.

I'd be happy to make the changes to adduser/deluser, but I'm waiting to
see what the consensus is going to be.  It seems that people largely
agree, but there are a few edge cases to iron out.

|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran@debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |

Attachment: signature.asc
Description: Digital signature

Reply to: