Adduser devel - Jul 2011 - adduser --system in maintainer scripts (re: Bug #634475)

On Mon, 30 May 2011 at 09:12:59 +0100, Stephen Gran
wrote:
> This one time, at band camp, Roger Leigh said:
> > [...] However, most
> > postinsts wrap the call to adduser with a check for whether the
> > account already exists [...]
> 
> 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
> postfix:x:112:120::/var/spool/postfix:/bin/false
> steve@varinia:~$ sudo adduser --system --quiet postfix
> [sudo] password for steve: 
> steve@varinia:~$ echo $?
> 0
We use adduser --system --quiet in the dbus package without checking for
existence of the user first, as recommended here. However, bug #634475
reveals that if the messagebus user is present, but is not in the system UID
range, this will make the upgrade fail.

Peter Chubb (reporter of #634475) wrote:
> Simon> If you have enough backups of /etc/passwd to be able to answer
> Simon> these questions: what were the messagebus user''s home
> Simon> directory, numeric UID, and primary group ID before the
> Simon> upgrade? What was the messagebus group''s numeric GID? 
Did you
> Simon> have any other users or groups whose numeric UID/GID collided
> Simon> with messagebus?
> 
> In the backup from two days ago:
> 
> : wombat ; grep messagebus passwd group
> passwd:messagebus:x:110:107::/var/run/dbus:/bin/false
> group:messagebus:x:107:
>  wombat ; grep 110 passwd
> messagebus:x:110:107::/var/run/dbus:/bin/false
> : wombat ; grep 107 group
> messagebus:x:107:
> 
> I think the issue I have is that because of legacy accounts,
> LAST_SYSTEM_UID is 99 in /etc/adduser.conf, and for some reason the
> account was already existing with a higher UID than that.
Presumably, on Peter''s system, messagebus was either created while
LAST_SYSTEM_UID was higher, or possibly before 2003 when dbus created
messagebus as a non-system group (#222563 - which was undeniably itself a bug,
but we should do what we can to recover from historical bugs).

In the opinions of the adduser maintainers, what should daemon-user-creating
packages like dbus be doing about this?

Thanks,
    S

This one time, at band camp, Simon McVittie said:
> On Mon, 30 May 2011 at 09:12:59 +0100, Stephen Gran wrote:
> > This one time, at band camp, Roger Leigh said:
> > > [...] However, most
> > > postinsts wrap the call to adduser with a check for whether the
> > > account already exists [...]
> > 
> > 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 at varinia:~$ getent passwd postfix
> > postfix:x:112:120::/var/spool/postfix:/bin/false
> > steve at varinia:~$ sudo adduser --system --quiet postfix
> > [sudo] password for steve: 
> > steve at varinia:~$ echo $?
> > 0
> 
> We use adduser --system --quiet in the dbus package without checking for
> existence of the user first, as recommended here. However, bug #634475
> reveals that if the messagebus user is present, but is not in the system
UID
> range, this will make the upgrade fail.
Correct, and this is arguably correct behavior.  I don''t think we want
to guess about what to do in this case.  The options available are:

renumber the account (and optionally find all files on the file system
        owned by this user and chown them to the new uid or delete them)
don''t renumber the account, which is in violation of debian and/or
local
        policy.

Neither is acceptable, frankly.  I think it''s best to fail in such a
way
that it forces the admin to deal with it.
> Peter Chubb (reporter of #634475) wrote:
> > Simon> If you have enough backups of /etc/passwd to be able to
answer
> > Simon> these questions: what were the messagebus user''s
home
> > Simon> directory, numeric UID, and primary group ID before the
> > Simon> upgrade? What was the messagebus group''s numeric
GID?  Did you
> > Simon> have any other users or groups whose numeric UID/GID
collided
> > Simon> with messagebus?
> > 
> > In the backup from two days ago:
> > 
> > : wombat ; grep messagebus passwd group
> > passwd:messagebus:x:110:107::/var/run/dbus:/bin/false
> > group:messagebus:x:107:
> >  wombat ; grep 110 passwd
> > messagebus:x:110:107::/var/run/dbus:/bin/false
> > : wombat ; grep 107 group
> > messagebus:x:107:
> > 
> > I think the issue I have is that because of legacy accounts,
> > LAST_SYSTEM_UID is 99 in /etc/adduser.conf, and for some reason the
> > account was already existing with a higher UID than that.
> 
> Presumably, on Peter''s system, messagebus was either created while
> LAST_SYSTEM_UID was higher, or possibly before 2003 when dbus created
> messagebus as a non-system group (#222563 - which was undeniably itself a
bug,
> but we should do what we can to recover from historical bugs).
> 
> In the opinions of the adduser maintainers, what should
daemon-user-creating
> packages like dbus be doing about this?
I think for this specific one, a change in local policy made the account
no longer correct, so again, I think adduser is behaving correctly here.

We have a whole class of bugs that want effectively an "ensure user is
in correct range" flag.  If this didn''t involve file ownership,
this
would be relatively straight forward, as we could just delete and
recreate them with the correct uid/gid.  Unfortunately, almost no package
that installs a user has no files owned by that user, so it gets a
little more complicated.

Cheers,
-- 
 -----------------------------------------------------------------
|   ,''''`.                                            Stephen
Gran |
|  : :'' :                                        sgran at debian.org |
|  `. `''                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL:
<http://lists.alioth.debian.org/pipermail/adduser-devel/attachments/20110724/70591d5a/attachment.pgp>