Re: user private groups and a src group
I shall delimit responses to different people with rows of `=' signs.
I've sorted my replies so that approximately what are IMO the most
sound, nonrepetitious and interesting arguments are near the top. I
have to say that I'm rather disappointed with the poor standard of
many of the arguments being used to oppose my proposal. I had hoped
for better from the developers' list.
I'm getting really quite tired of all the non-arguments against my
proposal, not the least of which is "other people don't seem to like
it."
====================
Remy Card writes:
> [ Source code control is a good thing, therefore ]
> 1. write access to a common set of files by a development team
> is not needed (and not even desirable) to achieve a project
> with efficiency,
Not every shared project has many people all updating the same source
files all the time, and therefore not every project needs to use RCS
or an equivalent.
And, as Matthew Birkholz has pointed out, RCS doesn't work unless the
users using it have shared access to the repository.
On very few of the shared projects I have worked on has it been
necessary to use source code control. Perhaps the projects I work on
have been less formally managed than others, but they prove the
existence (frequently!) of projects where this is the case.
>[rest of argument deleted as it doesn't follow if I refute the premise]
>
> Of course, I'll be glad to hear about conter examples (important
> ptojects which cannot be achieved with the help of a version control
> system and which require a change in the uid and gid attribution).
I have answered most of this above. However I'll also say that often
a version control system can be a help rather than a hindrance; even
if it were able to solve the same problem as the private groups
proposal (which it isn't) one shouldn't assume that it is the right
solution for everybody.
====================
Glen Reesor writes:
> These two quotes bring to mind an issue I haven't seen mentioned yet--
> that of sharing filesystems via NFS with machines that do *not* use
> this uid=gid method. Won't it be a major pain to align the two
> machines' group and passwd files??
No more than it is anyway. In this case the uid=gid can be abandoned
quite easily. You simply change the default umask to 022 and copy the
shared passwd and group files verbatim onto your system.
The setgid bit on each directory can be left alone, as it then ceases
to have any meaningful effect on the permissions of files created
there.
====================
Paul Vojta writes:
> Scripts just don't cut it. For starters, they either produce
> subshells which must be tediously nested, or have to be sourced or
> whatever and are thus a right royal pain.
>
> One can use aliases to source commands.
Yes, I'm aware of this; my description of it as a "right royal pain"
stands. It requires everyone who wishes to use these groups to make
bizarre shell-specific alterations to their dotfiles. They must then
remember each time they start and stop work in the shared filespace to
type the command (in each shell). They end up having several emacsen,
one for each umask/gid combination.
I have actually used systems like this, and it is a really serious
barrier to getting things done.
> The one major system I came across recently where it wasn't done
> wished they had done it, but they couldn't now because they'd already
> assigned the uid/gid numbers and they were too hard to change.
>
> This I don't understand. What is the value of having gid=uid?
You've misunderstood me. The reason they couldn't do it was because
it would require changing users' passwd and group entries on too many
different machines, etc., not because they'd already assigned the
gids.
However, having gid==uid is a useful feature to add to my proposal
because it enhances consistency and therefore makes administration
easier. It would also make it possible to (for example) go for
uid/gid unification in the kernel (cf the Hurd).
> I disagree. Outside of the kernel, how often is it really true that you
> have multiple users working on common projects? At the UCB math department,
> for example, the vast majority of users do not collaborate at all.
I have worked on numerous shared projects. I can't speak for all
users, of course, but given that the cost of my proposal is so low it
is silly to make life so awkward for those who wish to do this
perfectly reasonable thing.
> Regarding the kernel example, it is a dangerous practice, IMHO, to allow
> people to modify the kernel but not give them root access. They would then
> have both the ability and the incentive to introduce security holes into
> the kernel.
Do you always do your kernel compilations as `root' ? I don't like
to. It makes it more likely that I will (for example) accidentally
wipe out half my system with a misplaced `rm'.
Also, I'm not necessarily suggesting that the group of people with
write access to the kernel source should be greater than those who can
su to root with no password.
> Again, what is the benefit of having gid=uid?
See above. I believe that we should have gid=uid in Debian, for
consistency. It's not required for my proposal to work.
> This seems to be more of
> a religious issue than anything else.
Here "religious issue" seems to be being used by many as an excuse to
avoid finding rational arguments to support their position. There are
plenty of good arguments on our side, after all.
I'm not speaking from a "religious" perspective: the reason I believe
in this so strongly is because I have had extensive experience of this
problem and found that it _is_ serious and that the solution I am
proposing for Debian solves it easily, cleanly and effectively.
> But if you abandon that requirement,
> you can migrate quite readily from the old system to this one on an as
> needed basis: to switch joeuser to having his own group, just:
>
> 1. create a group named "joeuser" and add joeuser to it
> 2. chgrp -R joeuser ~joeuser
> 3. chmod g+s ~joeuser
No, that doesn't work. joeuser has to set his umask to 002 as well.
Then when he goes to edit system files, etc. for example (using su,
perhaps), the permissions will be wrong, unless you set g+s on each
directory.
If you do that you might as well make use of it properly.
Also, you have to do this for every person who becomes a member of a
shared project. Why go to all this trouble ?
> So why don't we keep the default debian behavior as it is currently, and
> allow an option in adduser (and /etc/defaults/adduser or wherever it is)
> to use Ian's system?
Why does the default have to be broken ?
====================
Carl Powers writes:
> Matt Hannigan writes:
> > However Ian Jackson
> > and I are both convinced that this scheme will bring no real changes
> > to the vast majority of debian users anyway, and a significant
> > advantage to those few that want to take advantage of group
> > permissions.
>
> The difference between 'vast majority' and 'all' is 'some'. Is that 'some'
> of less importance than 'those few' who would benefit from such a scheme?
You have not shown how my proposal harms the `some'. I don't believe
my scheme will significantly inconvenience *anyone* (well, anyone
reasonable).
> You and Ian have proposed a perhaps simple and elegant solution to a problem
> affecting 'those few'. Wouldn't it be better to provide a solution only
> applicable to 'those few', which could be selected or retrofitted at install
> time? I am one of the 'some'. I desire to keep my uid and gid separate and
> different on my linux box at work, to match those on the non-debian system I
> am hosted on. This avoids having to change ownership/permissions when
> transfering/downloading files between systems.
What's the problem here ? In your case you have to rip out Debian's
/etc/group and /etc/passwd files anyway, and can't use Debian's
adduser. The only additional work for you is to change the default
umask from 002 to 022.
Alternatively, as Matthew Hannigan suggests, you can just change the
umask and leave the /etc/group alone. After all, if your umask is 022
you're not using the groups anyway and the contents of /etc/group will
make little difference.
> Incidentally, technical feasability and need do not constitute the
> sole arguments for implementing any such change. You and Ian should be
> prepared to handle the 'philosophical' or 'religious' objections to such
> a change from the norm without insulting the intelligence of those who
> object.
I'm perfectly happy to answer genuine philosophical objections (Daniel
Quinlan has made a stab at one, for example). However saying that an
objection is "religious" is no excuse for failing to back it up.
Personally I feel that the proposal is an elegant solution to a
longstanding problem, and also one which fits in well with potential
future trends in the GNU software at least.
====================
Wayne Schlitt writes:
> I think we really need to question the premise that this change needs
> to be done at all. It is my understanding that the problem that this
> would solve is when you have lots of people working in the same
> directory tree. I guess I don't see that happening much for the
> typical debian user. I also don't see that it is going to be that
> hard for people to customize their environment in those cases that
> there are lots of people working in the same tree.
You obviously haven't tried this. I have.
In every case where I have had people sharing an area of filespace on
a Unix system exactly one of the following two things was true:
1. We had umask 002 and user private groups.
2. There were continual problems with setup files not running
correctly, files having the wrong permissions, security holes,
etc. etc. etc. It was a real pain.
> Maybe I am way off base on all of this. What exactly was the goal of
> this? What were the choices? I am embarassed to admit it, but I
> deleted the original messages that started this thread...
I shall repost my summary article from a few days ago, with some
clarifications.
> As usual
> with this type of thing, we have spent a lot of time picking minor
> holes in each others articles without looking at the whole.
I have hardly seen any holes at all picked by the "opposing" camp.
There have been very few messages even worth responding to. Finally
it seemed that in order to prevent argumentam ad nauseam from carrying
the day I would have to respond to them all, hence this message.
====================
Daniel Quinlan writes:
> I'd rather it was just the default Linux behavior, but it isn't going
> to happen. I wish that we didn't have to even think about mucking
> around with /etc/group.
The phrase `mucking around' is unjustifiably pejorative.
It appears to me as if you would like to see a more radical scheme,
more along the lines of the unification of user and group ids.
If this were to be done one would still need to specify somewhere
which groups had which actual users as members, and /etc/group is this
somewhere. In the straightforward implementation, therefore, each
user would end up with an entry in /etc/group anyway !
I don't think that giving every user their own group and corresponding
entry in /etc/group is ugly; it seems to me fairly neat and
orthogonal.
> Anyway, the fact of the matter is that I'm not
> even convinced that we want it. We will be getting good benefits, but
> the drawbacks are undeniable.
What drawbacks ?! I have seen NOONE come up with any genuine
drawbacks that weren't the result of misunderstanding on their part.
The only drawbacks at all (apart from misunderstandings) have been
- You have an entry for each user in /etc/group.
which is unbelievably trivial, and
- "The sgid bit will confuse people."
which is weak and has been adequately refuted.
> My mere question is: if the benefits are
> so undeniable, why can't this change occur everywhere and not just
> Debian?
It can. There's nothing stopping Slackware, TAMU, et al from
implementing exactly the scheme I describe. Indeed, I would like to
see them do so.
In any case, the argument you state above is fallacious. Just because
some other people have failed to do something doesn't mean it's a bad
idea.
> If the Linux community (or a significant majority) felt that
> this is a good change and Linus agreed, could we have a low-level
> change in directory semantics? I don't think POSIX defines anything in
> this area, but I haven't checked.
This is not a matter for the Debian list, more for the KERNEL channel
and/or col.development. I'd be very interesting to hear your ideas -
in the right place. Debian will have to work with the kernel as it is
now.
My proposal brings large benefits and has negligible costs. It has
been tried and found useful independantly in several places. It can
be implemented immediately.
====================
Bruce Perens writes:
> I'd like to call time on the uid=gid argument. I'm convinced this issue
> is not going to come to resolution through discussion here. Perhaps a
> demonstration would be more appropriate.
What is it you want me to demonstrate ? That it works ? Surely
that's obvious. That it's useful ? This is perhaps a little less
obvious if you've never worked on a shared project (especially an
informal one).
If people seriously doubt that sane use of the group write permission
is useful I can easily come up with several examples that I personally
have been involved with.
> The people who feel uid=gid is important are perfectly capable of
> building a package to implement it on top of a newly-installed release,
> including a script to change all permissions on every file in the
> distribution. Such a package can be installed on top of an existing
> Debian system with somewhat more difficulty than if the system came
> configured that way out of the box.
This is not a practical idea. The scheme has to be installed from the
very start, because the permissions of every directory need to be
considered and perhaps changed.
What you are suggesting would mean that the upgrade kit would have to
be updated every time a new package was added to Debian.
> Please don't ask everyone to take it on faith that uid=gid is appropriate.
I'm not. Strong arguments have been presented in its favour.
> And don't consider it overridingly important that you "save" every user
> by getting uid=gid into their system now. Put together a package that
> implements it. Show us how many users you get, and how they feel about it,
> and then you'll have the amunition to show that everybody's system should
> be configured that way.
Not practical. See above.
Also, why does the default have to be broken ?
.. and later (in response to Matthew Birkholz) ...
> I proposed that you make a demonstration and show us some satisfied users
> as a means of arriving at a consensus when you were obviously not going
> to get a priori acceptance of your proposal. "Show me" is not an attack
> on your ideas. There are enough demonstrations of the status quo. Show
> us a concrete system that's better and some users who like it.
I forget who it was, but someone posted recently on this list saying
that their system had a very similar scheme in operation and that it
worked well.
The Cambridge University's Central Unix Service has user private
groups, for exactly the purpose have outlined. It works well.
====================
Raul Deluth Miller writes:
> I think it's fairly obvious that we should provide a script to switch
> back and forth between the three configurations under discussion. I
> can write a "modgrp" script which changes the current configuration,
It is not obvious at all.
How will it cope with packages that are added to Debian after you
wrote your script ? It probably won't do it correctly.
> but I'm a little leary of re-writing something like adduser on the
> fly. Can we have a configuration file that tells adduser how to act?
Urgh. Why all this fuss ? What is it that people have against my
proposal ?
> Are there any other distinctions we wish to make about groups?
>
> Currently, I understand:
> bogus group (numeric id, but nothing in group -- can exist in
> /etc/passwd, or can exist in filesystem [requires find]).
> orphaned groups (no ids assigned to that group)
> groups with no signon id (id has * in password field).
> system groups with signon id(s) [usually root, and sometimes sysadmin].
> user groups [this can include things like guest].
I'm sorry, I fail to see what you are talking about.
====================
Stephen White writes:
> ...
> And [the] directories [which would be setgid] is [sic] where all the
> action occurs. With the setgid scheme, virtually all activity will
> be conducted under BSD semantics anyway.
False. Quite a lot of activity happens in /tmp and /usr/tmp, on my
system at least.
> ...
> Why bother with a weird system of permissions?
You're begging the question and using pejorative language: it's not `weird'.
> Why bother with the added
> complexity? It's so much easier to just mount the drive with bsd semantics,
> wack in an additional line in the "adduser" script, and be done with it. Two
> small changes. Simple.
The reason not to do this has been explained by Matthew Hannigan and
myself in considerable detail. You have not refuted our arguments.
--
Ian Jackson, at home <ijackson@nyx.cs.du.edu> or <iwj10@cus.cam.ac.uk>
PGP2 public key available on server. Urgent email: <iwj10@phx.cam.ac.uk>
2 Lexington Close, Cambridge, CB4 3LS, England; phone: +44 223 64238
Reply to: