Cleaning up the users and locking down the shells in /etc/passwd
ubuntu.com at mattalexander.com
Tue Sep 27 18:03:55 UTC 2011
On Tue, Sep 27, 2011 at 8:06 AM, Colin Watson <cjwatson at ubuntu.com> wrote:
> On Tue, Sep 27, 2011 at 06:12:24AM -0700, Matt Alexander wrote:
> > On Tue, Sep 27, 2011 at 1:28 AM, Colin Watson <cjwatson at ubuntu.com>
> > > I'm afraid this is backwards. If you want to go and hunt down packages
> > > that rely on those global static users and get their maintainers
> > > (preferably in Debian) to work on a migration to dynamically-allocated
> > > system users, perhaps after that it would be worth removing the global
> > > static users. Until then, they need to stay where they are.
> > Seems like detecting broken packages from system changes would already be
> > part of the Ubuntu qual. process.
> It's always better to not break things in the first place.
Sometimes breaking things is necessary for forward progress.
> > But, OK, I'll setup a box, remove users, and run a script that
> > installs/uninstalls everything one by one from the default repos and
> > makes note of any packages that break. I'll then open bugs with the
> > Debian maintainers of those packages to modify their install/uninstall
> > script.
> Sounds great, thanks!
> Note that I will not remove these users in any event:
> root (obviously)
> daemon (required by LSB)
> bin (required by LSB)
> sync (specialised, described in users-and-groups documentation)
> games (shared among many packages, likely to be too disruptive)
> man (man-db is widely installed anyway so any gain is not worth it)
> mail (often has many non-system-owned files, too disruptive)
> www-data (often has many non-system-owned files, too disruptive)
> nobody (obviously)
> You can refer to /usr/share/doc/base-passwd/users-and-groups.txt.gz for
> what's known about various system users.
> Great info. Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ubuntu-devel-discuss