[OpenAFS] Features great and small
Mon, 30 Jul 2001 18:02:33 -0400 (EDT)
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?)
> * 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
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
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) <firstname.lastname@example.org>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA