[OpenAFS] Setting the setacl on newly created volumes

[Charles Karney]

Charles Clancy writes:
 > From: "Charles Clancy" <mgrtcc@cs.rose-hulman.edu>
 > Date: Sat, 21 Jul 2001 10:42:47 -0500
 > 
 > > While I don't really see a problem allowing the owner to be specified
 > > for vos create, I'd like to point out that you can just create a
 > > kerberos principal that is in system:administrators that the AFS
 > > server has a key to and authenticates as.  It's certainly not a
 > > security exposure; given root on a db server, I can use pt_util to add
 > > something to system:administrators.
 > 
 > We did exactly that on our systems (K5/AFS).  We wanted to have a
 > web-based utility for users to change their passwords, and help-desk
 > staff to take care of basic tasks such as password resets and home
 > volume quota increases, without having direct access to an admin
 > account.  The web server has access to the keytab with the key, and the
 > scripts will "kinit;aklog;do-task;unlog;kdestroy" for each transaction
 > requiring administrative access.

Yes, I can see how this could be set up (although I would have to figure
out how to do it in with the AFS Kerberos infrastructure).

My concern is that serious mistakes can happen when shifting responsibility
to a sys admin who is new to AFS.  (E.g., as soon as root acquires a token,
all root-owned daemons inherit this token.  I've also had a problem of root
getting a token in a PAG and then restarting xdm --- then all new xdm users
shared a single PAG.  These are all mistakes I've made in past years!)

For this reason, I believe that allowing an -owner or -setacl specification
on 'vos create' would actually lead to a safer use of AFS in practise.
Furthermore the semantics of this option would seem to be quite natural
(paralleling the -maxquota flag).

-- 
Charles Karney			Email:	ckarney@sarnoff.com
Sarnoff Corporation		Phone:	+1 609 734 2312
Princeton, NJ 08543-5300	Fax:	+1 609 734 2586