[OpenAFS] Features great and small

[Jeffrey Hutzelman]

On Mon, 30 Jul 2001, Charles Karney wrote:

> * 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.

Yup.  So do most people, including CMU.  While uss might meet the needs of
someone running a small AFS cell in isolation, it really isn't up to the
generic task of user account maintenance.

> * 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.

Safer, maybe, but a lot more painful for the administrator.  It's also not
as big a problem as you make it out to be.  You can't run a Digital Unix
program at all on a Solaris box; the executable file formats aren't the
same.  Constructing a file which looked executable to both would take some
work, if it is possible at all.

> * Having the Unix find command know about volumes would be useful.  Maybe
>   the -xdev flag should restrain find to the volume it's in.

Maybe, or maybe it should be a different flag altogether.

> (An aside: is GNU find within AFS completely meaningless without -noleaf?)

Pretty much.


> * 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.

I think this goes with the above -- if find knew about mount points, it
could use "is a mount point" as a condition, in addition to being able to
avoid crossing them (in fact, just having the condition is enough -- if
you can tell whether something is a mount point, you can write a find
expression that does not cross it).

> * 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?)

For the most part, no.  The problem is that the suid bit is usually
applied at the VFS layer, in code that is common to all filesystems.  The
only chance a filesystem like AFS has to influence the process is through
the mode bits it presents for a file.  Since the mode bits returned by
stat(2) are the same bits used to decide whether to change the euid when a
program is executed, they cannot be different.

Of course, there may be some platforms which allow the filesystem to
participate directly in the suid decsion; on such a platform, it would be
possible to return the suid bits to stat without having them take effect. 
But there are few such platforms, if any.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA