Re: user private groups and a src group
email@example.com (Ian Jackson) said:
> The only things that should need changing are:
> * /etc/passwd and /etc/group: change the default gid of the default
> user and create their group, and possibly remove other conflicting
> * adduser needs to arrange to create people's groups as well as their
> passwd entries. It should also be written to skip a uid/gid if it is
> allocated in /etc/group as well as if it is in /etc/passwd, though
> one should allocate user groups and project groups in different
> ranges. An addgroup script might be nice; alternatively prominently
> leaving a large gap between assigned uids/gids and the start of the
> users might be enough.
> * Zillions of directories (almost all, in fact) should have the setgid
> bit set. This includes at least
> - user home directories
> - /usr/src
> - The entire /usr/local tree (which should presumably be group src)
> In fact, it might be easier to
> find / -type d -print0 | xargs -0 chmod -R g+s
> and then fix up the exceptions by hand. The only ones I can think of
> at the moment are /tmp and /var/tmp, though there may be others,
> especially belonging to some obscure packages.
And all of this will of course come as a complete suprise to debian
installers/users who have not been party to this discussion. They'll
need to be clued in about it, or it'll cause lots of confusion for them.
Come to think of it, some users will probably disagree with this scheme
on religious grounds. I'd say that the changes, particularly the adduser
changes, should be done so as not to present an obstacle to those who decide
they want nothing to do with a scheme which requires them to set the setgid
bit on almost all their directories. The most transparent way I can think
of to do that is with an internal variable in the adduser script which
controls whether this scheme is used or not. A script (or perhaps an
additional and somewhat obscure adduser option) which would massage the
directory permissions and the internal adduser variable setting might
also be a big help to users who start out one way and later decide they'd
rather switch, though it has a bit of a Rube Goldberg-ish feel to it.
Bottom line is that, as we've seen through the discussion which took
place here about this idea, it'll be unfamiliar and uncomfortable to many
who don't want a new and different way of doing things they're used to
doing their own way. If debian insists on the new and different method,
that will alienate some of those potential debian users.