[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: System accounts with valid shells

severity 184979 important
block 274229 by 184979

On Fri, Nov 01, 2013 at 09:26:15AM -0700, Russ Allbery wrote:
> Even if the risk is low, I see absolutely no reason why these accounts
> should have valid shells, and therefore don't understand why we wouldn't
> want to just change them to /usr/sbin/nologin.  The local administrator
> has other ways of getting a shell with that account by overriding the
> shell with su, etc., if they really want to interactively be that user.
> Colin, this bug has been dormant for a very long time, and I've previously
> pinged it with no response.  Is that just due to lack of time, or were you
> not sure whether this should change?  Is this something for which you want
> the broader advice of the project or the technical committee?

Sorry for not responding to this before (and CCing the bug now so that
this response is recorded properly).  I would like to fix this.  Of
course it needs due care and attention, but I don't think it especially
needs more discussion or broader advice.

However, there's an awkward problem blocking the change, namely #184979.
The last time I made any change to passwd.master or group.master that
caused update-passwd to prompt everyone to accept it was in December
2004.  Since then, the policy manual has been updated to say that all
packages must use debconf for prompting (albeit with an exception for
Essential and transitively-Essential packages, but only in that they may
have a fallback mechanism).  base-passwd is not in compliance with this
policy and it will require an extensive rewrite of update-passwd.c to
make it so.

This is absolutely an important problem and one I regard it as my
responsibility to solve; but, as long as I leave passwd.master and
group.master untouched, it is dormant.  If I change those files before
fixing that bug, however, then I know that I will unnecessarily
introduce problems for at least some of the package management tools
that have been developed on the reasonable Policy-derived assumption
that packages aren't going to do non-debconf-based prompting on upgrade.
For a less critical package, this might be an acceptable trade-off, but
base-passwd is pretty much certain to affect everyone and I don't think
I can justify knowingly introducing this kind of breakage.

I've been promising to fix #184979 for rather a long time now and have
been conspicuously failing to get round to it; from my local tree it
looks like all I ever managed to do was put together some template text.
Partially-working patches stand a good chance of getting me to debug
them into a more complete state, so I'd be glad of even incomplete
patches towards this.

Colin Watson                                       [cjwatson@debian.org]

Reply to: