FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-12-2011, 08:43 PM
"Scott Kitterman"
 
Default Bug#621833: System users: removing them

> On Tue, Apr 12, 2011 at 06:41:10PM +0100, Lars Wirzenius wrote:
>> (Cc to the relevant bug added.)
>>
>> On ma, 2011-04-11 at 14:05 +0100, Ian Jackson wrote:
>> > Lars Wirzenius writes ("Re: System users: removing them"):
>> > > Thus, I propose to change 9.2.2 "UID and GID classes", the paragraph
>> on
>> > > uids in the range 100-999, to add the following sentence to the end
>> of
>> > > the paragraph:
>> > >
>> > > Packages must not remove system users and groups they have
>> > > created.
>> >
>> > But shouldn't we say they _must_ lock package-specific system users
>> > and groups when the package is removed ?
>>
>> I think that's a good idea. Steve Langasek in the bug (#621833) and
>> others agree, so I think there's a strong consensus on that.
>
> Also, we need to provide a way for sysadmin to know they can safely remove
> a stale
> system user.

If we could do that, we could just remove them automatically and not
bother the sysadmin.

Scott K


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: f8952d63ff9c1e235707ab1e2a6b9318.squirrel@sm.webma il.pair.com">http://lists.debian.org/f8952d63ff9c1e235707ab1e2a6b9318.squirrel@sm.webma il.pair.com
 
Old 04-13-2011, 07:39 PM
Lars Wirzenius
 
Default Bug#621833: System users: removing them

On ti, 2011-04-12 at 21:31 +0200, sean finney wrote:
> Hi Lars,
>
> On Tue, Apr 12, 2011 at 06:41:10PM +0100, Lars Wirzenius wrote:
> > > But shouldn't we say they _must_ lock package-specific system users
> > > and groups when the package is removed ?
> >
> > I think that's a good idea. Steve Langasek in the bug (#621833) and
> > others agree, so I think there's a strong consensus on that.
>
> I don't think I'd agree there, at least without also addressing:
>
> * It also needs to limit the scope to locally defined users (i.e. not
> fail when it is unable to lock an NIS/LDAP/etc account).
> * There needs to be a way to explicitly do that with adduser or a similar
> tool[1][2][3][4].

Yes, and these were already suggested in the bug log, if I've undertood
everyone correctly (not all those mails were on -devel, though).

> Also, we haven't discussed what should be done in the case of a user
> account possibly shared between different packages, where any one of
> them may create it and 1..N of them might be installed.

In my opinion, those packages should arrange for things to work right
amongst themselves. The typical case would be to have a -common package,
which creates and locks down the user, and everything else depends on
it. But other options are also possible; I guess anything that achieves
the same effect should be OK by the policy manual.

--
Blog/wiki/website hosting with ikiwiki (free for free software):
http://www.branchable.com/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1302723569.2921.12.camel@havelock.liw.fi">http://lists.debian.org/1302723569.2921.12.camel@havelock.liw.fi
 
Old 04-13-2011, 09:06 PM
Leo 'costela' Antunes
 
Default Bug#621833: System users: removing them

On 12/04/11 22:43, Scott Kitterman wrote:
>> Also, we need to provide a way for sysadmin to know they can safely remove
>> a stale
>> system user.
>
> If we could do that, we could just remove them automatically and not
> bother the sysadmin.

Not necessarily. We can't be sure there aren't any files lying around
(at least not efficiently enough) to cause problems with UID reuse etc,
but we may inform the admin that at least from the packaging point of
view, the user/group isn't needed anymore. He can then decide to take
appropriate action if he feels the house-keeping is necessary.
It could simply be a matter of using the "User Name/Comment" field to
write something like "formerly used by package X; may be removed".
Admittedly not strictly necessary, but nice for those cases where you
check your /etc/passwd a few years later and ask yourself where that
user came from.


Cheers

--
Leo "costela" Antunes
[insert a witty retort here]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DA61068.8000102@debian.org">http://lists.debian.org/4DA61068.8000102@debian.org
 
Old 05-01-2011, 07:49 AM
Steve Langasek
 
Default Bug#621833: System users: removing them

On Tue, Apr 12, 2011 at 09:31:47PM +0200, sean finney wrote:

> I second your original proposal though, that packages must not delete
> system users that they have created. I don't think anyone had objections
> to that, and the question is whether things should be taken further.

I do object to telling maintainers they must not delete system users,
without also giving guidance on how and when to lock the accounts.

Sorry, no time at the moment to propose verbiage to reconcile this with your
concerns.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110501074903.GC11712@virgil.dodds.net">http://lists.debian.org/20110501074903.GC11712@virgil.dodds.net
 
Old 05-01-2011, 02:06 PM
Ian Jackson
 
Default Bug#621833: System users: removing them

Steve Langasek writes ("Re: Bug#621833: System users: removing them"):
> On Tue, Apr 12, 2011 at 09:31:47PM +0200, sean finney wrote:
> > I second your original proposal though, that packages must not delete
> > system users that they have created. I don't think anyone had objections
> > to that, and the question is whether things should be taken further.
>
> I do object to telling maintainers they must not delete system users,
> without also giving guidance on how and when to lock the accounts.

Yes, I agree with this.

> Sorry, no time at the moment to propose verbiage to reconcile this with your
> concerns.

I think the right thing to do would be to have deluser lock (rather
than delete) system users when invoked in the way currently used by
maintainer scripts. Provided that doesn't make interactive use of
deluser break somehow.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 19901.26824.984819.316632@chiark.greenend.org.uk"> http://lists.debian.org/19901.26824.984819.316632@chiark.greenend.org.uk
 
Old 05-01-2011, 02:42 PM
Andreas Barth
 
Default Bug#621833: System users: removing them

* Ian Jackson (ijackson@chiark.greenend.org.uk) [110501 16:39]:
> Steve Langasek writes ("Re: Bug#621833: System users: removing them"):
> > On Tue, Apr 12, 2011 at 09:31:47PM +0200, sean finney wrote:
> > > I second your original proposal though, that packages must not delete
> > > system users that they have created. I don't think anyone had objections
> > > to that, and the question is whether things should be taken further.
> >
> > I do object to telling maintainers they must not delete system users,
> > without also giving guidance on how and when to lock the accounts.
>
> Yes, I agree with this.
>
> > Sorry, no time at the moment to propose verbiage to reconcile this with your
> > concerns.
>
> I think the right thing to do would be to have deluser lock (rather
> than delete) system users when invoked in the way currently used by
> maintainer scripts. Provided that doesn't make interactive use of
> deluser break somehow.

Good idea.


I agree that system users should never be removed by maintainer
scripts, but as said: Someone would need to write that down before
starting to behave so.


Andi


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110501144217.GH15003@mails.so.argh.org">http://lists.debian.org/20110501144217.GH15003@mails.so.argh.org
 
Old 05-29-2011, 11:04 AM
Roger Leigh
 
Default Bug#621833: System users: removing them

On Sun, May 01, 2011 at 03:06:00PM +0100, Ian Jackson wrote:
> Steve Langasek writes ("Re: Bug#621833: System users: removing them"):
> > On Tue, Apr 12, 2011 at 09:31:47PM +0200, sean finney wrote:
> > > I second your original proposal though, that packages must not delete
> > > system users that they have created. I don't think anyone had objections
> > > to that, and the question is whether things should be taken further.
> >
> > I do object to telling maintainers they must not delete system users,
> > without also giving guidance on how and when to lock the accounts.
>
> Yes, I agree with this.
>
> > Sorry, no time at the moment to propose verbiage to reconcile this with your
> > concerns.
>
> I think the right thing to do would be to have deluser lock (rather
> than delete) system users when invoked in the way currently used by
> maintainer scripts. Provided that doesn't make interactive use of
> deluser break somehow.

I've been looking at how this might be accomplished right now, and
have these observations to make. (These are WRT my addition and
removal of the "sbuild" user in the sbuild package.)

1) Locking on removal.

This is as simple as doing (in postrm)

# Lock sbuild account.
usermod -U -e 1 sbuild

However, one does now need to consider how "unlocking" will occur
if the package is reinstalled, which I don't think has been covered
as yet:

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

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.

I've added this after the above to unlock if locked:

# Unlock account in case it was locked from previous purge.
usermod -U -e ' sbuild

This appears to reverse the locking, via inspection of the
shadow record. However, "" isn't documented as a valid
value for EXPIRE_DATE (it's the default in /etc/default/useradd
though).

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.

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.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
 
Old 05-29-2011, 11:55 AM
Roger Leigh
 
Default Bug#621833: System users: removing them

On Sun, May 29, 2011 at 12:04:35PM +0100, Roger Leigh wrote:
> On Sun, May 01, 2011 at 03:06:00PM +0100, Ian Jackson wrote:
> > Steve Langasek writes ("Re: Bug#621833: System users: removing them"):
> > > On Tue, Apr 12, 2011 at 09:31:47PM +0200, sean finney wrote:
> > > > I second your original proposal though, that packages must not delete
> > > > system users that they have created. I don't think anyone had objections
> > > > to that, and the question is whether things should be taken further.
> > >
> > > I do object to telling maintainers they must not delete system users,
> > > without also giving guidance on how and when to lock the accounts.
> >
> > Yes, I agree with this.
> >
> > > Sorry, no time at the moment to propose verbiage to reconcile this with your
> > > concerns.
> >
> > I think the right thing to do would be to have deluser lock (rather
> > than delete) system users when invoked in the way currently used by
> > maintainer scripts. Provided that doesn't make interactive use of
> > deluser break somehow.
>
> I've been looking at how this might be accomplished right now, and
> have these observations to make. (These are WRT my addition and
> removal of the "sbuild" user in the sbuild package.)
>
> 1) Locking on removal.
>
> This is as simple as doing (in postrm)
>
> # Lock sbuild account.
> usermod -U -e 1 sbuild

Oops, should of course be "usermod -L -e 1 sbuild"

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
 
Old 05-29-2011, 07:32 PM
Roger Leigh
 
Default Bug#621833: System users: removing them

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


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
 
Old 05-30-2011, 08:12 AM
Stephen Gran
 
Default 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
postfix:x:112:120::/var/spool/postfix:/bin/false
steve@varinia:~$ sudo adduser --system --quiet postfix
[sudo] password for steve:
steve@varinia:~$ echo $?
0
steve@varinia:~$

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.

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

Thread Tools




All times are GMT. The time now is 08:24 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org