"Richard Basch" writes:
> I forgot to deal with the claim that the PT groups aren't flexible
> enough to handle the namespace of users and machines.
>
> Why not?
First we have 10,000 users at the College of Engineering. Since the pt
server doesn't handle large groups well, i.e., a single group with > 2K
entries, we're forced to rely on the use of system:authuser as an ACL when
we'd rather specify a pt group that had all of our users (or some subset) in
it. When you consider the UM as a whole and a potential of 100,000 members,
being limited to about 2% of the total member community in the number of
entries in a single group is a serious flaw.
We also have over 3,400 IP addresses that we keep track of. While not
all of these are AFS clients, a majority are and there isn't a good
way of combining users with addresses and be spcific about it. The
only way around this seems to be in the use of system:authuser in
some combination of other ACLs. This is hard to maintain, hard
to explain to lay persons, and defeats any notion of people who are not
system admins, maintaining their own ACLs.
Second, Bill Dosters' message makes clear the advantages of supporting
pt groups within pt groups. As Bill says "We've found it very useful
for delegating control and administration". This has got to be one
of the best reasons for this. There are other obvious uses as well.
For example, at a university many people come and go. keeping track
of all of the pt groups that someone may belong to is a pain to say the
least. Another nice thing is that by making a change to one group, you
may inturn affect the ACL on a number of disimilar directories without
having to go through each one and exmaine/modify its membership.
Groups within groups would at least in my mind, be a much better model
for the notion of combining people and machines than something like:
system:hosts l
system:users r
I *really* wish Transarc would pick this up from Bill's group and make it
available to the AFS community at large.
> AFS 3.2a allows you to use wildcarding of hosts.
So does AFS 3.2 but whether intentionally or not, the meaning has changed
in 3.2a. However, if you think that specifying IP addresses in ACLs is
unsecure, then what must you think of wildcards?
> system:authuser is already a special group that automatically contains
> all users. How many host entries do you have to add to the ptserver, if
> you use wildcarding? Probably, it is a drop in the bucket...
We, as a matter of practice, put each and every IP address for each and
every AFS client we manage into our pt server. For us, using the 3.2
wildcards was not so bad because the IP address had to be in the pt server,
but in 3.2a that changed to include any AFS client, whether the IP
address was in th pt server or not. Ceratinly the use of wildcards in 3.2a
is a little better than system:anyuser, but only a little.
> Putting groups within groups would be nice, I agree... There is a
> lookup cost (and rather costly),
Their is a look up cost in using a nameserver too. And in finding a
volume, etc.. The flexibility it gives you is a trade off with the
cost.
> I don't see how groups within groups changes the overloading o
> system:authuser problem. This is a tangential problem. [By the way, we
> are NOT running the nested group environment in the Athena cell.]
As it stands today, using AFS 3.2 or 3.2a, both people and machines who
are in your PT server come in as system:authuser. People have typed
a password, and machines just becuase the IP address is in the pt server.
When you consider that you can't represent your user community as a
small number of pt groups contained in bigger groups, that you can't
maintain a single large group, and that licensed software from OS commands
to 3rd party apps should be available on a machine not user basis, that
only leaves system:authuser to fill several roles.
What I'm objecting to in all of this is that given the fact that
the pt server does not handle large groups well, that one can't specify
groups within groups, and that IP wildcards are less secure in afs 3.2a
than in afs 3.2, only system:authuser seems to be left to use. And
now Transarc is thinking about changing that too.
< Paul
