[OpenAFS] Features great and small

Charles Karney ckarney@sarnoff.com
Mon, 30 Jul 2001 11:49:10 -0400 (EDT)


Now that AFS is an open-source project, there's a hope to get a bunch of
usability features implemented.  I don't think any of these are
make-or-break issues.  However, they address a some awkward points with AFS
which are likely to be off-putting to new AFS users and admins.

Here's my list

* readline interface for kas and backup in interactive mode.  The benefits
  should be obvious.

* kas should take the password from the terminal not from stdin, this would
  allow

    kas -admin admin < file
    Administrator's (admin) Password:

  to be used to issue multiple kas commands safely.  Currently it uses the
  first line in the file as the password!  For obvious reasons I don't want
  to use

    kas -admin admin -password xxxx

* It should be possible for kas to create an account with a disabled
  password.  This would allow accounts to be set up in bulk with the
  password setting defered until the user is present.  Of course

      kas create -initial_password xxx

  is for the birds.  How about

     kas create ... -disable_password

  Possibly

     kas create ... -copy_password admin

  to allow the password to be copied from the administrator's account so
  that the adminitstrator and the user can jointly use kpasswd to update
  the password at a later time.

* uss has an unnecessary eight-character limit on user names.  I only know
  about this for the Transarc version.  In fact, I find the whole uss
  mechanism to be rather clumsy, and have since started using my own scripts
  to set up accounts.

* The default password for "uss add" should be disabled, not the string
  "changeme".  (What were the coders of uss thinking about?)

* fs setcell is too coarse-grained a way of offering suid functionality.
  Many sites offer binaries for multiple platforms via AFS.  This means
  that an suid program for Digital Unix can be run as a suid program on a
  Solaris system with undefined consequences.  It would be safer to have
  the suid functionality on a per-volume basis.

* It's frequently necessary to change the ACL on a whole directory tree and

    find . -noleaf -type d -print0 | xargs -0r fs sa -acl NEWACL -dir

  is rather a mouthful.  How about

    fs setacl -dir dir+ -acl acl+ -recursive [-onevolume]

  -onevolume means that this should stay within a volume (a piece of
  functionality that not easily available by other means).

* I would like to be able to set the AFS owner of directories.  chown isn't
  very good for this since it looks the owner up in the wrong place
  (/etc/passwd, NIS, or whatever).  This would also allow an AFS GROUP to
  OWN a directory (a concept which is meaningless in the Unix world).  Thus

    fs setowner -dir dir+ -owner [-recursive [-onevolume]]

* Having the Unix find command know about volumes would be useful.  Maybe
  the -xdev flag should restrain find to the volume it's in.  (An aside: is
  GNU find within AFS completely meaningless without -noleaf?)

* I would like a convenient way of finding AFS mount points on an AFS
  client (e.g., a extension of 'find . -type X').  salvager -showmounts
  offers this functionality on the server side and not in a very managable
  form.

* A gotcha with SUID files is that if a cell in -nosuid, then

     install -m 4755 file directory

  actually does install the file with the SUID bit on (as you will discover
  if you subsequently change the cell to -suid).  However, "ls -l" on the
  directory does not show this.  If you want to find any suid files in AFS
  you have to run "salvager -showsuid" on the server.  Again the same
  functionality on the client would be nice.  (With Unix partitions mounted
  -nosuid, "ls -l" still reports the suid bits.  Could this work with AFS
  too?)

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