AFS splits up notions of privilege into 3 areas:
(1) BOS - *EACH* db and fs server has a "UserList" file that
describes who that server thinks is god. Only
those people are allowed to do bos operations
and it seems certain other operations.
This is probably the most powerful privilege;
because you can muck with almost all the
machinery of the server. One of the weaknesses in
AFS 3 is that this is true of every file server;
it's not really possible to delegate out authority
to just one file server without also giving them
at least the ability to affect everything in the
cell.
(2) KA - have the ADMIN bit.
Affects operations on kaserver - kas.
This privilege allows you to change the key of
"any user", and so you can become anybody
in system:administrators in (3) - so this
is a greater degree of trust. It also allows
you to set the key for anybody in a UserList,
so it's equivalent to (1). But it's less powerful
than (1) because only kaserver uses the ADMIN bit,
and it's hard to do anything else without leaving some
sort of trace behind (if you don't *know* a key you can't
fetch it directly, so you can't get into BOS without changing
at least one password.)
(3) PT - in system:administrators
Affects operations in pt server, and perhaps some
other operations (I'd have to go look to find out
which). You can't use it to change ka keys,
or to muck with the machinery of the servers,
so there is probably the least degree of trust
in being a member of system:administrators.
In your case, volume creation seems to requires that you be
in the UserList file for *THAT* file server. "bos adduser"
can be done on each server to enable that.
Incidently, you don't have to do a "unlog" before you "klog".
I find it helpful to use "pagsh" when I need to be admin; that
way I can still be myself in other windows, and I can even
suspend & resume the admin shell if need be (although you
should be *especially* careful of leaving your terminal unattended &
accessible if you do this!) Um, if you are making yourself
the equivalent of "admin", then you need to be *very* careful
at *all* times.
It is a curious property of AFS that you don't actually
have to have an "admin" user ID. Also, in being a member of
"system:administrators" you are not in any sense "admin";
you are yourself and you just happen to have some (or all)
of the same privileges as admin.
If you want to delegate out volume creation authority, but not other
privileges, you basically need to find or write a server to act as an
intermediary. ADM (from CMU) is one possible solution. If you do try
to get ADM running, I suggest using afs 3.2b libraries; the result
is likely to be more stable.
-Marcus Watts
UM ITD RS Umich Systems
