On Sun, May 29, 2011 at 12:04:35PM +0100, Roger Leigh wrote:
> 2) Reinstallation.
>
> I'm currently using this logic (in postinst)
>
> # Create dedicated sbuild user
> if ! getent passwd sbuild > /dev/null; then
> adduser --system --quiet --home /var/lib/sbuild --no-create-home
> --shell /bin/bash --ingroup sbuild --gecos "Debian source builder" sbuild
> fi

Cheking for the account already being present in postinst should not
be necessary. Adduser is designed to do the right thing without
additional logic in maintainer scripts. If it doesn't, please file a
bug.

If people find it desireable to automatically unlock an existing
account on adduser --system <name>, this could easily be implemented
in adduser, doing the right thing to locked accounts. If that may be
necessary, please file a bug against adduser.

> I do agree that a --local option would be a valuable and useful
> addition to the adduser and deluser etc. tools, even if currently
> a no-op. However, due to the above I don't think that adding
> special-case user locking to deluser is the correct course of action.

What should the --local option do? If you want adduser to grow this
option, please file a bug.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110530084313.GB27807@torres.zugschlus.de">http://lists.debian.org/20110530084313.GB27807@torres.zugschlus.de

On Sun, May 29, 2011 at 08:32:21PM +0100, Roger Leigh wrote:
> We could add special behaviour to adduser to unlock the account
> if it already exists when run in the postinst.

Yes.

> However, most postinsts wrap the call to adduser with a check for
> whether the account already exists,

Which would be a bug in the 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.

adduser --system is designed (and, IIRC, documented) to have the
effect of "after the call to adduser --system, the account will exist
and is useable. The only case when adduser --system really errors out
is when the account already exists but is not a system account."

> 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.

The would be rather easy. Account creation/unlocking would happen with
an unwrapped call to adduser --system, account locking with a call to
the appropriate back-end command, or we could add an lockuser command
to the adduser package. I think, the latter would be preferable since
we would then be able to add sugar to the locking process. A wishlist
bug against adduser is in order.

Greetings
Marc, with a rather worn and dusty adduser hat on

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110530084708.GC27807@torres.zugschlus.de">http://lists.debian.org/20110530084708.GC27807@torres.zugschlus.de

On Mon, May 30, 2011 at 10:47:08AM +0200, Marc Haber wrote:
> On Sun, May 29, 2011 at 08:32:21PM +0100, Roger Leigh wrote:
> > 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.
>
> The would be rather easy. Account creation/unlocking would happen with
> an unwrapped call to adduser --system, account locking with a call to
> the appropriate back-end command, or we could add an lockuser command
> to the adduser package. I think, the latter would be preferable since
> we would then be able to add sugar to the locking process. A wishlist
> bug against adduser is in order.

And at the same time, we add a check to lintian suggesting lockuser if
deluser was detected in p{ost,re}rm. And while we're at it, a check for
a nested adduser call as described by Roger could be added, too.

Hauke

--
.'`. Jan Hauke Rahm <jhr@debian.org> www.jhr-online.de
: :' : Debian Developer www.debian.org
`. `'` Member of the Linux Foundation www.linux.com
`- Fellow of the Free Software Foundation Europe www.fsfe.org

On Sun, May 29, 2011 at 12:04:35PM +0100, Roger Leigh wrote:
> I'm currently using this logic (in postinst)
>
> # Create dedicated sbuild user
> if ! getent passwd sbuild > /dev/null; then
> adduser --system --quiet --home /var/lib/sbuild --no-create-home
> --shell /bin/bash --ingroup sbuild --gecos "Debian source builder" sbuild
> fi
>
> However, consider that if the account is locked, the user already
> exists and no unlocking will occur, leaving the reinstalled
> package broken. This logic is common to many packages.

That's a bug in a lot of packages, yes. adduser has been designed to
allow adduser --system to be called without that logic:

If called with one non-option argument and the --system option, adduser
will add a system user. If a user with the same name already exists in
the system uid range (or, if the uid is specified, if a user with that
uid already exists), adduser will exit with a warning. This warning can
be suppressed by adding "--quiet".

So, just remove the extra getent passwd check and you should be fine.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120701095311.GA7924@torres.zugschlus.de">http://lists.debian.org/20120701095311.GA7924@torres.zugschlus.de

On Sun, May 29, 2011 at 08:32:21PM +0100, Roger Leigh wrote:
> We could add special behaviour to adduser to unlock the account
> if it already exists when run in the postinst.

Yes, that would be the way to go for adduser --system

> 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.

Yes, packages having used that approached are buggy in the first place.

> It would also alter the existing behaviour of adduser, which is to
> return nonzero if the user already exists, which could cause
> breakage.

NACK, adduser --system does return zero if the user already exists and
its parameters are sufficiently similiar to the parameters requested
by the maintainer script.

> 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.

NACK, don't put the same logic into a hundred maintainer scripts where
they'll have two hundred different bugs. Put the logic into a central
place where bugs can be handled centrally.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120701095539.GB7924@torres.zugschlus.de">http://lists.debian.org/20120701095539.GB7924@torres.zugschlus.de