>I agree that the problems for administrators posed by groups within
>groups can be a mess but it would be the job of the administrator to
>maintain control.
Not easily done at really big sites like Umich, UNCC, IBM-Austin -
sites with tens of thousands of users and hundreds of departments and
projects that potentially need special groups.
>One solution might be to have an additional switch in the "pts
>creategroup" command which will allow groups to be added to the new
>group (i.e. -groups). The default would be as it is now, with no groups
>allowed.
Yes, but who gets to use this new feature? Just sys admins may be
good enough for smaller sites, but for the example of a department
head managing groups for his dept - he's not a sys admin (and
shouldn't be) and he may well want to create groups that can contain
groups (and maybe you want to allow that). Lets assume just sys
admins can use this feature. The sys admin issues the commands
% pts cg history -groups (to allow it to contain groups)
% pts chown history -owner depthead
(Better yet, make history self owned and put depthead and
admin-assistant in the history group.)
Anyway, now depthead can do this:
% pts cg history:students
But, he can't do this
% pts cg history:students -groups
Which is what he wants to do because he intends to create
history:undergrads and history:grad-students and wants to put those 2
groups into history:students.
Unless the depthead knows exactly what he intends the heirarchy of his
future groups to be when you are helping him out in the first place,
you'll end up with a frustrated depthead and will be frustrated
yourself. Multiply this by 100 departments and you get an idea of
what CMU, UMich - the large sites - are facing.
Desirabilty of the feature is clear. Implimentation is a problem for
our developers should this become a high enough priority to be
addressed. What we need to do is weigh the advantages with the
dangers and make a decision on who can use the feature and what
constraints will be placed on them.
I don't think a simple division of "sys:admin can, non-sys:admin
can't" is good enough for most of our sites. I'm not convinced that
allowing everyone to have *random* groups in groups is a wise idea.
Hence the idea of allowing history groups to contain history groups
and pierette groups to contain pierette groups. This may not be the
ideal solution for everyone (there's no such thing). My questions
are:
1. Is this a *reasonable and useful* solution for everyone (better
yet, I should phrase it as "is this an INsufficient solution for
anyone")
2. Does anyone have any other recommendations that meet two criteria:
1. Provides the feature to those who need it (who are not
necessarily sys:admins)
2. Prevents a naive facultly member from unwittingly giving
his students read access to the homework dropoff
directory:
% fs la /afs/cell/math/211/homework
joeprof:211-students lik
joeprof:graders rlidwk
where joeprof:graders looks like:
joe
sue:TAs
sue
franks:people
franks:friends
random undergrads
Remember that doing a recursive pts mem (pts mem
-long?) when he adds joeprof:graders to the ACL isnt
good enough. Frank can add his friends group to his
people group at any time after the homework ACL has
been set.
Pierette
