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 03-31-2011, 08:23 AM
Lars Wirzenius
 
Default System users: removing them

We have some packages that require a dedicated user to be created, and
calling "adduser --system" in postinst does that. However, it is not
always clear whether such users should be removed when the package is
removed.

* The user might be administered centrally, via LDAP. (So postinst
never actually created it, and thus postrm shouldn't remove it.)
* There might be files owned by the user that the package does not
know about.
* There might be other site policies about this.

The easy solution for this would be to never remove the user, but that's
also not so clear.

* Extra accounts are just wasteful, and may cause some confusion.
* There is a tiny risk of having unused accounts on the system.
(We have tens of them anyway, but still.)

Most hosts, however, can safely remove the system user when the package
is removed, if the user is to be removed at all. There may be cases
where a package's system user should not be removed, because some files
that belong to it will not be removed, such as a Usenet spool.

I propose the following:

* We patch deluser to check for a boolean DELETE_SYSTEM_USERS
setting in /etc/adduser.conf. If set to false, it does not
remove the user. Default the setting to true, since that is
status quo and works for most hosts and sites. Maybe also add a
--force option to override the config file setting?
* Review all packages and their use of adduser/deluser. Make sure
that they don't have unnecessary scaffolding ("if ! getenet
passwd ..."), since it's unnecessary, and also not needed. Make
sure they have the appropriate call to deluser in postrm. Add a
versioned dependency to packages to make sure they depend on a
version of adduser that implements DELETE_SYSTEM_USERS.

Would this be a good thing to do? Comments? Problems I've forgotten
about?

Would a debhelper tool to create/remove system users be useful? I
suspect there's only relatively few packages that do that, so perhaps
not.

I earlier blogged about an "addsysuser" tool[0], but Stephen Gran
pointed out to me that it's mostly unnecessary scaffolding. In my blog
post I also outlined a way for packages to share a system user, without
having to depend on it, but I think that's not so useful, so I don't
include it in this proposal.

[0] http://blog.liw.fi/posts/addsysuser/
[1] http://i.imgur.com/3XuAi.jpg (gratuitous cat picture; NSFW language)

--
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: 1301559813.11500.34.camel@havelock.liw.fi">http://lists.debian.org/1301559813.11500.34.camel@havelock.liw.fi
 
Old 03-31-2011, 01:18 PM
Ian Jackson
 
Default System users: removing them

Lars Wirzenius writes ("System users: removing them"):
> The easy solution for this would be to never remove the user, but that's
> also not so clear.

To remove a user and reclaim the uid is a difficult business.

> * Extra accounts are just wasteful, and may cause some confusion.
> * There is a tiny risk of having unused accounts on the system.
> (We have tens of them anyway, but still.)

I think a disabled account present in passwd (with changed home
directory, and starred out shadow entry) is less risk than a reused
uid.

> Most hosts, however, can safely remove the system user when the package
> is removed, if the user is to be removed at all. There may be cases
> where a package's system user should not be removed, because some files
> that belong to it will not be removed, such as a Usenet spool.

IMO the accounts should be retained but disabled.

> I propose the following:
>
> * We patch deluser to check for a boolean DELETE_SYSTEM_USERS
> setting in /etc/adduser.conf. If set to false, it does not
> remove the user. Default the setting to true, since that is
> status quo and works for most hosts and sites. Maybe also add a
> --force option to override the config file setting?

The current default is not to delete the user because packages don't
generally do so, surely ?

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 19860.32563.116133.70976@chiark.greenend.org.uk">h ttp://lists.debian.org/19860.32563.116133.70976@chiark.greenend.org.uk
 
Old 03-31-2011, 03:29 PM
Scott Kitterman
 
Default System users: removing them

On Thursday, March 31, 2011 04:23:33 AM Lars Wirzenius wrote:
> We have some packages that require a dedicated user to be created, and
> calling "adduser --system" in postinst does that. However, it is not
> always clear whether such users should be removed when the package is
> removed.
>
> * The user might be administered centrally, via LDAP. (So postinst
> never actually created it, and thus postrm shouldn't remove it.)
> * There might be files owned by the user that the package does not
> know about.
> * There might be other site policies about this.
>
> The easy solution for this would be to never remove the user, but that's
> also not so clear.
>
> * Extra accounts are just wasteful, and may cause some confusion.
> * There is a tiny risk of having unused accounts on the system.
> (We have tens of them anyway, but still.)
>
> Most hosts, however, can safely remove the system user when the package
> is removed, if the user is to be removed at all. There may be cases
> where a package's system user should not be removed, because some files
> that belong to it will not be removed, such as a Usenet spool.
>
> I propose the following:
>
> * We patch deluser to check for a boolean DELETE_SYSTEM_USERS
> setting in /etc/adduser.conf. If set to false, it does not
> remove the user. Default the setting to true, since that is
> status quo and works for most hosts and sites. Maybe also add a
> --force option to override the config file setting?
> * Review all packages and their use of adduser/deluser. Make sure
> that they don't have unnecessary scaffolding ("if ! getenet
> passwd ..."), since it's unnecessary, and also not needed. Make
> sure they have the appropriate call to deluser in postrm. Add a
> versioned dependency to packages to make sure they depend on a
> version of adduser that implements DELETE_SYSTEM_USERS.
>
> Would this be a good thing to do? Comments? Problems I've forgotten
> about?
>
> Would a debhelper tool to create/remove system users be useful? I
> suspect there's only relatively few packages that do that, so perhaps
> not.
>
> I earlier blogged about an "addsysuser" tool[0], but Stephen Gran
> pointed out to me that it's mostly unnecessary scaffolding. In my blog
> post I also outlined a way for packages to share a system user, without
> having to depend on it, but I think that's not so useful, so I don't
> include it in this proposal.
>
> [0] http://blog.liw.fi/posts/addsysuser/
> [1] http://i.imgur.com/3XuAi.jpg (gratuitous cat picture; NSFW language)

It seems to me that there is not a clear statement about removing users on
purge in policy. I'd prefer we get consensus around the policy before diving
into implementation on this.

Personally I think the risks associated with removal are greater than the
potential benefits and, except in unusual cases, they should be left. I've
got one bug open against one of my packages that I'd love to be able to close
with "No, policy says X and so the current behavior is correct." I'm willing
to accept it the project decides I'm wrong, but I'd like to see a clear
statement on what the right thing to do is.

Scott K


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201103311129.38869.debian@kitterman.com">http://lists.debian.org/201103311129.38869.debian@kitterman.com
 
Old 04-04-2011, 08:09 PM
Lars Wirzenius
 
Default System users: removing them

On to, 2011-03-31 at 14:18 +0100, Ian Jackson wrote:
> Lars Wirzenius writes ("System users: removing them"):
> > The easy solution for this would be to never remove the user, but that's
> > also not so clear.
>
> To remove a user and reclaim the uid is a difficult business.

This is true in the general case, but for most systems it is easy: users
and uids on my laptop, for example, are not shared elsewhere. I expect
most systems to be like my laptop.

There are systems where they leak, and where removing a user is more
difficult. That's why I would like to make it configurable by the admin.

> > * Extra accounts are just wasteful, and may cause some confusion.
> > * There is a tiny risk of having unused accounts on the system.
> > (We have tens of them anyway, but still.)
>
> I think a disabled account present in passwd (with changed home
> directory, and starred out shadow entry) is less risk than a reused
> uid.

Since I don't see any problem in removing unused accounts on my laptop,
I judge the risks differently from you.

However, the risk of an unused and properly locked down account is low
enough that I am happy to live with un-purged package specific system
accounts if that's what we decide to have.

> The current default is not to delete the user because packages don't
> generally do so, surely ?

I ran the attached script (same as the one I attached to my previous
mail, to the bash thread) to unpack all amd64 sid/main binary packages,
and then grepped for use of adduser or deluser in maintainer scripts:

find pool -name postinst -o -name preinst -o -name postrm -o
-name prerm | xargs grep adduser > adduser.list

And the same, replacing adduser with deluser. The lists are a few tens
of kilobytes in total, so I won't attach them to the mailing list, but
I've put them on the web:

http://files.liw.fi/temp/adduser.list
http://files.liw.fi/temp/deluser.list

There seem to be 106 maintainer scripts that mention deluser, in 103
packages. (I did not manually verify that they're all actually calling
deluser.)

I think this would be a good point to have a discussion and set policy
on how to deal with this. The policy manual seems to currently be silent
about removing users created by the package at installation time.

* We can decide that packages may not remove the accounts they
create, ever. In that case, we should amend Policy to say this
explicitly, do an MBF on the packages in the deluser.list above,
and add a lintian warning against calling deluser in maintainer
scripts.
* We can decide to have deluser read a config setting when
removing system accounts (my earlier proposal). This would allow
a little bit of de-cluttering, but perhaps not enough to warrant
the complexity.
* We can't decide, of course, that packages must always remove the
accounts they create, because the uid re-use and leaking
problems are real.

Did I miss an option? What do others think? What's the sensible thing to
do here?

--
Blog/wiki/website hosting with ikiwiki (free for free software):
http://www.branchable.com/
 
Old 04-05-2011, 06:37 AM
Tollef Fog Heen
 
Default System users: removing them

]] Lars Wirzenius

Hi,

| I think this would be a good point to have a discussion and set policy
| on how to deal with this. The policy manual seems to currently be silent
| about removing users created by the package at installation time.
|
| * We can decide that packages may not remove the accounts they
| create, ever. In that case, we should amend Policy to say this
| explicitly, do an MBF on the packages in the deluser.list above,
| and add a lintian warning against calling deluser in maintainer
| scripts.

I think never deleting is the most sensible solution, the reasoning
being:

- UIDs are a cheap resource (we can use 32 bit uids nowadays), the
overhead in /etc/passwd and friends is neglible.
- Most or all system accounts are locked and unable to be used for
login. Perhaps policy should say that user accounts belonging to a
package must be locked when the package is removed?
- The possible downside of reusing a UID is real.
- Giving the admin a way to set policy to delete users means we have
more code paths to test, meaning the likehood of bugs popping up
increases.

The same argument applies for system gids and groups, btw.

Regards,
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87hbad2ogg.fsf@qurzaw.varnish-software.com">http://lists.debian.org/87hbad2ogg.fsf@qurzaw.varnish-software.com
 
Old 04-05-2011, 06:50 AM
Russ Allbery
 
Default System users: removing them

Tollef Fog Heen <tfheen@err.no> writes:

> - Most or all system accounts are locked and unable to be used for
> login. Perhaps policy should say that user accounts belonging to a
> package must be locked when the package is removed?

Speaking of that, fixing Bug#274229 and the merged bugs for wheezy would
sure be nice.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 8762qtdwdq.fsf@windlord.stanford.edu">http://lists.debian.org/8762qtdwdq.fsf@windlord.stanford.edu
 
Old 04-09-2011, 08:44 AM
Lars Wirzenius
 
Default System users: removing them

Package: debian-policy
Version: 3.9.2.0

thanks

Background for the policy list: see thread starting at
http://lists.debian.org/debian-devel/2011/03/msg01174.html
and continuing in April at
http://lists.debian.org/debian-devel/2011/04/msg00210.html

On ma, 2011-04-04 at 21:09 +0100, Lars Wirzenius wrote:
> > The current default is not to delete the user because packages don't
> > generally do so, surely ?
>
> I ran the attached script (same as the one I attached to my previous
> mail, to the bash thread) to unpack all amd64 sid/main binary packages,
> and then grepped for use of adduser or deluser in maintainer scripts:
>
> find pool -name postinst -o -name preinst -o -name postrm -o
> -name prerm | xargs grep adduser > adduser.list
>
> And the same, replacing adduser with deluser. The lists are a few tens
> of kilobytes in total, so I won't attach them to the mailing list, but
> I've put them on the web:
>
> http://files.liw.fi/temp/adduser.list
> http://files.liw.fi/temp/deluser.list
>
> There seem to be 106 maintainer scripts that mention deluser, in 103
> packages. (I did not manually verify that they're all actually calling
> deluser.)
>
> I think this would be a good point to have a discussion and set policy
> on how to deal with this. The policy manual seems to currently be silent
> about removing users created by the package at installation time.
>
> * We can decide that packages may not remove the accounts they
> create, ever. In that case, we should amend Policy to say this
> explicitly, do an MBF on the packages in the deluser.list above,
> and add a lintian warning against calling deluser in maintainer
> scripts.

Ian and Tollef and Scott Kitterman are against removal of system users,
and nobody (except, very mildly, me) is for their removal, so I guess
the consensus on -devel is clear: we should not remove system users,
ever, in maintainer scripts. If an admin wants to do it manually, that
is, of course, OK.

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.

Not sure if a mass bug filing is warranted if this policy change is
accepted, but definitely a lintian check would be in order (I'm happy to
write it).

--
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: 1302338668.2441.60.camel@havelock.liw.fi">http://lists.debian.org/1302338668.2441.60.camel@havelock.liw.fi
 
Old 04-09-2011, 09:14 AM
Roger Leigh
 
Default System users: removing them

On Sat, Apr 09, 2011 at 09:44:28AM +0100, Lars Wirzenius wrote:
> Package: debian-policy
> Version: 3.9.2.0
>
> thanks
>
> Background for the policy list: see thread starting at
> http://lists.debian.org/debian-devel/2011/03/msg01174.html
> and continuing in April at
> http://lists.debian.org/debian-devel/2011/04/msg00210.html
>
> On ma, 2011-04-04 at 21:09 +0100, Lars Wirzenius wrote:
> > > The current default is not to delete the user because packages don't
> > > generally do so, surely ?
> >
> > I ran the attached script (same as the one I attached to my previous
> > mail, to the bash thread) to unpack all amd64 sid/main binary packages,
> > and then grepped for use of adduser or deluser in maintainer scripts:
> >
> > find pool -name postinst -o -name preinst -o -name postrm -o
> > -name prerm | xargs grep adduser > adduser.list
> >
> > And the same, replacing adduser with deluser. The lists are a few tens
> > of kilobytes in total, so I won't attach them to the mailing list, but
> > I've put them on the web:
> >
> > http://files.liw.fi/temp/adduser.list
> > http://files.liw.fi/temp/deluser.list
> >
> > There seem to be 106 maintainer scripts that mention deluser, in 103
> > packages. (I did not manually verify that they're all actually calling
> > deluser.)
> >
> > I think this would be a good point to have a discussion and set policy
> > on how to deal with this. The policy manual seems to currently be silent
> > about removing users created by the package at installation time.
> >
> > * We can decide that packages may not remove the accounts they
> > create, ever. In that case, we should amend Policy to say this
> > explicitly, do an MBF on the packages in the deluser.list above,
> > and add a lintian warning against calling deluser in maintainer
> > scripts.
>
> Ian and Tollef and Scott Kitterman are against removal of system users,
> and nobody (except, very mildly, me) is for their removal, so I guess
> the consensus on -devel is clear: we should not remove system users,
> ever, in maintainer scripts. If an admin wants to do it manually, that
> is, of course, OK.
>
> 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.

This does sound like a sensible addition. Will the packages be
responsible for locking the accounts?

I've always found the addition and removal of user accounts in
maintainer scripts difficult, due to the huge difference in
practice between packages, and the lack of detailed guidance on
best practice. Would it be worth adding explicit examples of
how to add system users and groups in Policy. Also, would it
be worth adding support to debhelper or dpkg-maintscript-helper
to do the user addition--it would unify the process so that
packages won't have to reinvent the wheel, and make things
much more simple and reliable.


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 04-09-2011, 12:21 PM
Lars Wirzenius
 
Default System users: removing them

Adding a copy to the bug report.

Everyone please Cc 621833@bugs.debian.org if replying to this subhtread.
Thanks.

On la, 2011-04-09 at 10:14 +0100, Roger Leigh wrote:
> On Sat, Apr 09, 2011 at 09:44:28AM +0100, Lars Wirzenius wrote:
> > Package: debian-policy
> > Version: 3.9.2.0
> >
> > thanks
> >
> > Background for the policy list: see thread starting at
> > http://lists.debian.org/debian-devel/2011/03/msg01174.html
> > and continuing in April at
> > http://lists.debian.org/debian-devel/2011/04/msg00210.html
> >
> > On ma, 2011-04-04 at 21:09 +0100, Lars Wirzenius wrote:
> > > > The current default is not to delete the user because packages don't
> > > > generally do so, surely ?
> > >
> > > I ran the attached script (same as the one I attached to my previous
> > > mail, to the bash thread) to unpack all amd64 sid/main binary packages,
> > > and then grepped for use of adduser or deluser in maintainer scripts:
> > >
> > > find pool -name postinst -o -name preinst -o -name postrm -o
> > > -name prerm | xargs grep adduser > adduser.list
> > >
> > > And the same, replacing adduser with deluser. The lists are a few tens
> > > of kilobytes in total, so I won't attach them to the mailing list, but
> > > I've put them on the web:
> > >
> > > http://files.liw.fi/temp/adduser.list
> > > http://files.liw.fi/temp/deluser.list
> > >
> > > There seem to be 106 maintainer scripts that mention deluser, in 103
> > > packages. (I did not manually verify that they're all actually calling
> > > deluser.)
> > >
> > > I think this would be a good point to have a discussion and set policy
> > > on how to deal with this. The policy manual seems to currently be silent
> > > about removing users created by the package at installation time.
> > >
> > > * We can decide that packages may not remove the accounts they
> > > create, ever. In that case, we should amend Policy to say this
> > > explicitly, do an MBF on the packages in the deluser.list above,
> > > and add a lintian warning against calling deluser in maintainer
> > > scripts.
> >
> > Ian and Tollef and Scott Kitterman are against removal of system users,
> > and nobody (except, very mildly, me) is for their removal, so I guess
> > the consensus on -devel is clear: we should not remove system users,
> > ever, in maintainer scripts. If an admin wants to do it manually, that
> > is, of course, OK.
> >
> > 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.
>
> This does sound like a sensible addition. Will the packages be
> responsible for locking the accounts?
>
> I've always found the addition and removal of user accounts in
> maintainer scripts difficult, due to the huge difference in
> practice between packages, and the lack of detailed guidance on
> best practice. Would it be worth adding explicit examples of
> how to add system users and groups in Policy. Also, would it
> be worth adding support to debhelper or dpkg-maintscript-helper
> to do the user addition--it would unify the process so that
> packages won't have to reinvent the wheel, and make things
> much more simple and reliable.
>
>
> Regards,
> Roger
>

--
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: 1302351687.2441.80.camel@havelock.liw.fi">http://lists.debian.org/1302351687.2441.80.camel@havelock.liw.fi
 
Old 04-11-2011, 01:05 PM
Ian Jackson
 
Default System users: removing them

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 ?

In which case, we need packages to still call deluser (as most do) and
deluser to do the right thing. I think we should sort this out before
changing policy, so we know what it is package maintainers are
supposed to do.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 19874.64686.98445.806467@chiark.greenend.org.uk">h ttp://lists.debian.org/19874.64686.98445.806467@chiark.greenend.org.uk
 

Thread Tools




All times are GMT. The time now is 01:50 PM.

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