User private groups - reply to Remy Card (devel)
(This message is essentially a bunch of responses to issues and points
left over after Ian Murdock's proposal.)
Remy Card writes:
> [much wibbling about RCS deleted]
I'll not respond to this in detail. David Engel has stated clearly
the mistake you're making here.
> 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.
No, my proposal does work (as does Ian's compromise) as well as any
system. Under these circumstances you have to put up with what you're
given anyway; my proposal doesn't make it any harder to conform to
your site's practices. In fact, if your site does user private groups
it will actually gain you something ...
> 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.
This can easily be solved by using nested directories appropriately:
drwxr-s--- 7 imurdock readers 512 Mar 25 00:08 /project/foo
drwxrwsr-x 10 imurdock writers 2048 Mar 25 00:08 /project/foo/work
I can see that some people might consider this less elegant than
having a umask of 027; however it does allow you to control access to
files based on their location rather than by changing your umask all
the time.
I have worked on systems where file protection is based on the name of
the file and it really is very convenient indeed - it's also bloody
obvious and hard to make mistakes about.
(H. Peter Anvin tells me that he also made a similar point earlier on
and that I "dismissed [it] with a handwaving without giving an
adequate solution". If so I apologise. However I don't remember
responding to any of his messages, so perhaps I just missed it.)
> Can you please explain this `uid/gid unification in the kernel' ?
> [stuff deleted]
Well, it goes like this: you arrange for the kernel to no longer
distinguish between uids and gids. Your process merely has a list of
zero or more ids attached, some of which will belong to you personally
and some of which will belong to groups of people. You still need to
have a `uid' and `gid' to say what ownership to give created files,
but they're just used there (of course they'd be in the list as well).
Then it becomes possible (for example) to make a file owned by a
group, so that any member of the group may chmod/chown it.
As I understand it the Hurd will be doing something like this (though
probably not necessarily with particularly unix-like permission
information attached to files - I don't know about this). I've gained
this impression from reading various technical information about the
Hurd.
(Note to the potentially confused reader: the above 3 paragraphs are
*not* part of the `user private groups' proposal that I've been
arguing in favour of on this list!)
> 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.
Yes, thank you, I'm well aware of this kind of issue. Debian doesn't
contain such a group, however there's no reason some people shouldn't
be allowed to have one if they want it.
The way I've implemented this on my system is to make some
security-critical file (/etc/inittab, I believe) writeable by the
group in question. Then I have a suid-root program that will
automatically let you in if you have write access to this file.
This would be a nice feature to have in the `su' in Debian (perhaps
using a writeability check on `/'), which would allow people to make
this kind of thing a matter for local policy.
> 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?
Because I'm not a BSD developer, beta tester, documentation
maintainer, etc. Rest assured that if I were I would be pressing for
my proposal there just as hard as I am here.
> [ re more radical kernel changes ]
>
> > 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.
It's not `needed'. Whether it would be nice is another thing. If it
would be nice it would be nice in the standard kernel, at least as an
option - this is therefore *not* a Debian-specific issue.
Given the astonishing negative response I've had on this list to a
commonly used and effective scheme I don't think more radical and
ideas whose usefulness might even be slightly doubtful would go down
at all well.
> > 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 Cambridge University Computer Society and the C.U. Science Fiction
Society both maintain filespaces on various multiuser systems. These
filespaces are kept writeable by the committee; portions are readable
only by the membership, other portions are globally readable. The
filespaces generally contain things like shared mail folders used for
accessing a society mailbox (locking was done by the mailer - only one
person could use the mail folders at a time), publicity material,
libraries of commands useful to committee members and or ordinary
users (these libraries are maintained by one person, but the committee
all need write access to fix urgent problems, etc.)
I'm currently working on a project to replace a bulletin board system
running on the IBM Phoenix/MVS mainframe here. On the IBM the Editors
have a shared filespace which they all have access to. The software
is changed infrequently and doesn't need revision control, and the
message spool area is protected by operating system locking
techniques. The replacement is a TCP/IP-based server, however I'm
currently having some difficulty because (due to political problems)
I'm not allowed to use the shared filespace allocated on the Central
Unix Service for the `replacement bulletin board'. This makes it much
harder to share files with my co-developers. If and when the politics
are sorted out all the stuff will go in the shared filespace. Again,
revision control is not necessary, because all the major software
development is being done by only one person per large component;
however shared access to administrative data, message spools, etc, is
vital.
My 2rd-year `software engineering' project, where I was working with
one other person in a shared filespace. We weren't editing "each
others'" files, though we had a shared source/build tree. If we
needed `conflict resolution' we spoke to each other - we were
generally working on adjacent workstations. We were given a shared
filespace but had to use newgrp and umask to access it correctly - the
results were difficult to manage.
> 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?
Here's another example:
Systems in general are often managed by groups of people rather than
single individuals. It makes life a lot easier if all the relevant
files are accessible to the relevant people - you can just type `make
install' and have it work without worrying too much about permissions.
All the members of the `mail' group can go and edit the config files,
clear stuck queues, etc, without having to su and type passwords all
the time.
> ... . Allowing a group of users to modify these directories
> may create security risks.
That depends on who the groups of users are and what they could do
anyway, clearly. Your point ?
> 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?
Please see Matthew Hannigan's message and my followup, and my more
recent message in response to Stephen White. I'm sad to see that I
have to repeat myself and refer people back to things I've already
said so much.
> 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.
Please do not do this.
BSD behaviour for a whole filesystem is both a kludge and unexpected,
and making it the default is even worse.
Please read the messages from Matthew Hannigan and myself, which
listed around 4 reasons not to do this.
Reply to: