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/
unpack-debian-binaries
Description: application/shellscript
