Re: user private groups and a src group
Hi,
I am sorry that waste more bandwith by replying to this thread but
Mr Jackson does not seem to accept that other people may have other opinion
so I have to reply to explain again.
Ian Jackson writes:
> ====================
>
> 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.
Well, this depends how you understand `many'. IMO, the word `many'
can be used as soon as there is more than one developer.
> And, as Matthew Birkholz has pointed out, RCS doesn't work unless the
> users using it have shared access to the repository.
No, this is wrong. The users need to have shared write access on
the directories in the repository if you use RCS. If you use CVS, you don't
have to care since CVS sets group write access on directories in 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.
Of course, unmanaged projects exist, but do you think that we have to
promote them? I'd prefer to see the use of version control system promoted
for shared projects instead of suggesting people to modify the same set of
files without any coordination.
> >[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.
I'm sorry but you did not answer. I still have to see you describe
a big project which cannot be achieved with the help of a version control
system.
> 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.
The use of a version control system can solve the problem. Let's
state it again :
1. with a version control system, users do not have write access to
shared files stored in the repository,
2. with a version control system, users have to checkout the files and
work on a copy of the development files,
3. users can change the working copies, test the changes, debug them
and commit them (checkin the files) when they are satisfied,
4. since users work on their own copies of the files, they do not need
to have a permissive umask (i.e. 002),
5. thus, there is no need for the proposal if you accept the use of
version control system.
If you don't use any version control system, several risks exist:
1. user A and B edit the same file, A writes his changes, the B writes
out his own changes and erases modifications made by A,
1. user A has several files to change to add a new feature, A makes
changes in a few files, B starts using the shared files before
A completes his changes thus using an inconsistent set of files.
Please note that I don't claim that version control systems are the
only solution or even the best one. I just suggest that their use should be
considered.
> ====================
>
> 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.
So, your proposal does not work in a networked environment where a
PC running Linux needs to interact with NFS servers which use the de-facto
standard way of attributing uid and gid? If so, this is a big restriction.
> 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.
You seem to consider that the group inheritance is only useful for
sharing write access to files. I do not agree. At our university, we use
this to allow read access to some files for some users belonging to the
same group (with umask = 027). Even if a shared write access is not needed,
groups can still be use to share read access.
> ====================
>
> Paul Vojta writes:
> >
> > This I don't understand. What is the value of having gid=uid?
>
> 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).
Can you please explain this `uid/gid unification in the kernel' ? As
far as I know (and I am a kernel developer so I suppose that I should now), the
kernel only uses uid and gid to test for access permissions on files and on
processes (e.g. the kill system call). The kernel itself does not care about
the attribution of uid/gid. The only literal test made on uids is the
macro `suser' which tests if the effective uid of the current process is 0
(i.e. the current process runs with root priviledges).
> > 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'.
I think that you misunderstood Paul's words. Paul was meaning that
letting users change the kernel source files may be very dangerous. If these
users introduce bugs in the kernel, these bugs will be activated next time
the administrator compiles the new kernel and boots it.
> 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.
What's that? Does Debian contain a group that is allowed to su root
without any password? If so, this may open a security risk since this may be
easier to guess one of N passwords than the single root password to get
superuser priviledges.
I prefer a scheme where an admin group exists (call it the name you
want, I don't care) and only members of this group are allowed to su root but
they have to know the root password. This is the way BSD works. OK, the su
command from GNU does not implement this feature but this should be quite easy
to add it.
> > 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 ?
This sentence is pejorative. Why don't you say `Why does the default
have to be something that I consider to be broken' ?
> ====================
>
> Carl Powers writes:
> >
> > 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 are offensive again by implying that only unreasonable persons
may disagree with you.
> 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.
This is wrong. Groups can be used to control shared read access on
files as I have explained above.
> 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.
How about adding a third thing:
3. We were using a version control system and we had no problem accessing
the common repository. Moreover, the version control system was very
useful to detect and correct conflicts.
> ====================
>
> 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.
Hey, Mr Jackson, don't you think that the most offensive mail comes
from you ? Your mails contain lots of insults for people who disagree with
you:
- every argument against your proposal is said to be a non argument,
- you say that every reasonable person should agree with you implying
that every opponent to your proposal is not reasonable,
- you state that every other opinion `is broken',
- and so on ...
Sometimes, you look to me like Bill Jolitz and the *BSD folks who
cannot accept that someone does not fully agree with them...
> > 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.
Hmm, why do you restrict you to Linux distributions? Go ahead, Mr
Jackson, extend your proposal to other Unix distributions. Why don't you
propose that your private groups idea be implemented in the BSD distributions
for example?
> 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.
I agree with you here. Simply saying that nobody has implemented it
is not enough to say that it's a bad idea. But, I think that one should
consider other people's solution too and it seems to me that you did not
bother investigating other's solution before submitting your proposal. Why
don't you ask existing development teams how they work. Ask CMU, ask the FSF,
ask the BSD folks, ask the Kerberos team, ask the X Consortium about their
solutions, try to understand them and consider them.
> > 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.
I strongly disagree. I think that people can discuss some needed
extensions to the kernel before submitting a proposal to the KERNEL channel
and/or the filesystem developers. After all, if an extension is needed for
Debian, it can be discussed on a this mailing list and submitted to the
kernel developers if/when there is a consensus on it.
> ====================
>
> 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.
>
> 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.
Please describe them. You always say `I can easily give real examples'
but you never explain them. Can you please describe them to serve as a basis
for future discussion.
> > 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.
Hmmm, I don't understand. I thought that permissions had to be changed
on user and project directories. Why should we change the permissions on
the system and application directories?
> Also, why does the default have to be broken ?
Oh no! Not again!
> .. 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.
Yes, and I can say that projects I have been involved in have been
well managed (with version control systems) and everything works well too.
> ====================
>
> 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.
Again, why do you want to extend the proposal to system and application
directories? Allowing a group of users to modify these directories may create
security risks.
> > 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 ?
Don't be paranoid. Some people may have other solutions to the same
problem and you should be prepared to a debate when you propose a change.
> ====================
>
> 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.
Hu? You store project and user directories in /tmp and/or /usr/tmp?
> > 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.
The only argument against mounting filesystem with BSD semantics seems
to be `what happens if the administrator removes the bsd option from
/etc/fstab. Using setgid directories opens the same risks: what happens if
the administrator or the directory owner removes the setgid bit?
BTW, it seems to me that this thread gives me the opportunity to
suggest the changes in the default behavior for directory semantics. As I
said before in this list, I am willing to change the ext2fs default behavior
to use BSD semantics and implement it in other filesystems. I will contact
other filesystem developers to check if they have objections and then I will
send a proposal on the KERNEL channel.
> --
> 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
--
Remy Card
card@masi.ibp.fr
"The shame was on the other side, we can be heroes for ever and ever"
Reply to: