Re: user private groups and a src group
Summary: every one of Paul Vojta's points is unsound.
NB: beware of the fallacy `he has so many arguments that some of them
have to be right.'
Paul Vojta writes, regarding the private groups proposal:
> 1. It clogs up /etc/groups unnecessarily. Sometimes I want to know what
> groups are out there; currently "more /etc/groups" will tell me without
> making me wade through a list of all the users on the machine.
This will still be true, if you do the sensible thing and have all the
users' groups higher-numbered and hence (by convention) later-placed
in the /etc/group file than the system and project groups.
(This is the sensible thing because there are likely to be more user
private groups than project and system groups, at least until some
software exists for users to manipulate /etc/group in a safe way.)
> 2. Some software may break if there are too many groups. No, I can't name
> anything specific here, but this possibility at least suggests that
> we not jump into this with both feet.
This is pure FUD (Fear, Uncertainty and Doubt), and not a real
argument at all. It's also false, for all the software I've
encountered. The Cambridge University Computing Service don't seem to
have had any problems with it on SunOS 4 and Solaris 2, for example.
> 3. We'll be continually burdened with newbies asking why we adopted this
> weird system.
This is false, I believe (anyone who notices and wonders will probably
be clueful enough to find the FAQ or an appropriate manpage).
Even if it were true to a small extent, if we are to allow this kind
of argument to prevail we might as well give up trying to make Debian
look like Unix.
> 4. Many people use SLIP; I plan to be one of them shortly. They will want
> their user and group setup on their local machine to match or be a
> subset of the user and group setup on the remote machine. Ditto for NFS.
As Matt Birkholz has pointed out, this is no harder if Debian comes
with user private groups by default.
> 5. It has not been fully described. For example, what happens if I create
> a file in /tmp? The answer depends on whether a user's primary default
> group is his private group or some larger group.
The user's primary group (the one in /etc/passwd) is their private
one.
> 6. Not all sites have groups of users collaborating on projects. What
> percentage do is open for dispute, but certainly it is not a solution
> to a universal problem.
Uhh, just because not everyone has the problem it shouldn't be
solved ??
Password checking isn't needed at all sites, either - many if not most
home machines can do fine without login, crypt and passwd. So shall
we remove those too ?
> 7. It does not completely solve the problem. As Remy Card recently pointed
> out in his message, it has no facility for preventing two users from
> simultaneously editing the same file. For this reason one may even regard
> the proposal as dangerous.
No, Remy Card has merely pointed out that it doesn't solve a different
problem.
> 8. Other solutions exist, viz. RCS. I have never used RCS myself, as I
> have not collaborated on any software with anyone else on the same machine.
> However, I would like to respond to something that you wrote in response
> to Remy Card's message:
No, RCS is a solution to a different problem. In fact, as Matt
Birkholz points out it needs something like the private groups
arrangement to work correctly, unless it is to be set-id (urgh!).
> -----
> [Discussion of retrofitting omitted.]
> It would be persistently tedious every time a
> package installs itself with inappropriate permissions.
>
> Could you elaborate on this a bit? What packages? I don't see why
> package permissions would be different under user private groups than under
> the usual setup.
Most files in the filesystem should look like they were created with
the default umask of 002, and be owned by an appropriate group.
Directories should have the setgid bit set in most cases.
For example, the news data and spool areas (/var/{lib,spool}/news)
should be 2775 news.news, so that the news administrator can just
/usr/lib/news/bin/maint/addgroup site.local.foo.bar.wombat y
without having to mess around with `su' or `really'.
This kind of thing can't easily be retrofitted, because the
retrofitter would have to know in advance which files have to be
changed in all new packages that might appear.
> If we take it as the default, why wouldn't we want it to be
> excellent right from the start?
>
> For my purposes it's excellent the way it is, thank you.
That is a very selfish attitude. Why screw up many people's systems
just because `for my purposes it's excellent [this way]' ?
> [...] I was feeling the same way when I posted my
> last message. Ian's been saying that we should pack up the standard Unix
> way of doing things,
I don't think it can be called a "standard". My proposal is a
departure from convention, it's true - but it is a tried and tested
one that has proven its stability and usefulness.
> which does work if you know how,
False. The conventional umask of 002 *doesn't* work. Don't try to
tell me that it does - I've been on systems where it has been tried.
Don't try to tell me I don't know how, either - at least not without
coming up with your description of how it should be done (NB RCS is
*not* the answer here: as Matt points out, it's the answer to a
different problem).
> and take a hike.
Unjustifiably pejorative language, and untrue.
> His reasons were (A) we need uid==gid,
Please stop calling it `uid==gid', you'll just confuse people
(yourself included, it seems).
> and because of that (B) it's impossible to retrofit,
No, I don't claim that your (B) follows from (A).
> so we should put everybody on this system starting from day one.
> But you've conceded that (A) is wrong, and nearly conceded (B).
Huh?
You have obviously misunderstood, so I shall spell it out for you:
1. Some people need group-write umask and hence user private groups.
2. Group-write umask and user private groups imply some changes to
the permissions of many files throughout the system.
3. Because of 2, group-write umask and user private groups are
hard to retrofit.
4. Group-write umask and user private groups have no serious
disadvantages.
5. (Because of 1, 3 and 4:)
Group-write umask and user private groups should be the default.
> Let's step back for a minute and think about the general situation.
> The problem that Ian's method addresses is not specific to Linux; it is
> equally likely to happen on any Unix or Posix system. Ian's solution uses
> methods that are not specific to Linux; they could be used on any Unix or
> Posix system. Why has nobody else implemented this as a standard part of
> a distributed system?
This is a fallacious in two ways.
Firstly it is of the form `noone else has done this so it must be
bad', and secondly the premise (that noone else has done it) is false.
You should know this as several people, myself included, have posted
to this list to say so.
> (a) Ian is so much brighter than the the thousands who came before.
Ha ha. I'm only one of several people I know who have `invented' this
idea independantly of each other.
> (b) Solutions to the problem already exist, and they are equally good
> or better.
>
> I'm willing to grant that Ian's solution is quite clever, but mainly
> I believe that (b) is the case.
*What* other solutions ?
> I have no objections to allowing user private groups to be an optional
> part of debian, with scripts to switch back and forth. But maybe you can
> give (valid and detailed) arguments why it has to be mandatory.
Firstly, see above for details of why retrofitting is difficult.
Secondly, it wouldn't be mandatory, it would be the default. If you
didn't like it switching it off would be much easier than switching it
on (even if you had to edit adduser manually). OK, you'd still have
most of the directories setgid, but you can change the umask and
delete the additional groups, which will enable you to interwork
successfully with (for example) NFS servers and clients with broken
group configurations.
However, having said that, I'm convinced that in practice noone other
than those whose uids and gids are constrained by their site would
bother, because this scheme will cause problems for noone !
Ian.
PS: I'd be very grateful if people would actually read the messages
that are posted before trying to respond.
Reply to: