Well, there are lots of other ways Joe Freshman could get into
trouble and probably does. For instance, convincing him
not to share his new secret password with others is a perennial
problem almost everywhere. Even with the existing pts groups,
he might well decide to set the flags on "joef:best.friends" to
"SOMar", his best friends might well add their best friends,
and that could well result in Joe's worst enemy belong to
his group. In fact, there is evidence that suggests that
one's worst enemies probably *are* one's best friends, so
the only way I can think of to completely avoid this situation
is to eliminate Pts groups altogether, and perhaps AFS at the
same time, which is surely a case of throwing the baby out with the
bath water. If we take this assumption "user's can't be trusted"
to its logical but absurd conclusion, we find that Karesh was onto
something! :-)
If anything, this is a case, not for limiting power of the
software, but for better user education materials. And that means,
basically much more complete online materials and other materials
suitable for reproduction or even modification for end-user
requirements. When "joef" types "man pts", he shouldn't
get just a list of the commands, but he should also get
a description of the output and affects of those commands,
which should be enough to incidently describe a fairly detailed
functional descrition of the pt database. If Mr. T.
Professor wants to describe "just the things they
need to know about AFS to get by" he should not need to
expect his students to buy 2,000 copies of the AFS User's Guide.
He ought to be able to tuck away 25 xerox'd pages in his
course pack and not worry about it further. The same is true
of the corporate environment - only the problem isn't so bad
since cells are likely to be smaller & turnover less. This
obviously won't work for every user (nothing ever does)
but it should at least address a large body of users, particularly
in larger organizations, who are currently pretty much left
out in the cold documentation-wise.
So far as "limiting" groups within groups to same ownership,
consider this:
I want to create a group "mdw:enemies" that contains
all the people I want to specifically exclude from looking
at my files. I know that, for instance, that "history:tas",
"itd:management", and "itd.umich:staff" are not
trustworthy. So, why shouldn't I be able to create a group containing
these groups, and use that on negative acl's on all my directories?
For my purposes, it's convenient that "somebody else" manages all these
groups. Note also that I don't manage any of these groups, and that
these groups are in turn managed by separate organizations (perhaps
they don't trust each other more than I trust them.)
-Marcus Watts
UM ITD RS Umich Systems Group
