Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!athena.mit.edu!jfc
From: jfc@athena.mit.edu (John F Carr)
Newsgroups: comp.unix.wizards
Subject: Re: What kinds of things would you want in the GNU OS?
Message-ID: <11856@bloom-beacon.MIT.EDU>
Date: 6 Jun 89 08:04:43 GMT
References: <106326@sun.Eng.Sun.COM> <4315@ficc.uu.net> <338@arc.UUCP> <208@sopwith.UUCP> <3306@cps3xx.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: jfc@athena.mit.edu (John F Carr)
Organization: Massachusetts Institute of Technology
Lines: 62

In article <3306@cps3xx.UUCP> rang@cpswh.cps.msu.edu (Anton Rang) writes:

>Just out of curiousity, is anyone out there using the Andrew system
>(AFS)?  I've been told that the machines hooked up to it have a truly
>transparent file system (i.e. a friend of mine at Univ. of Mich. can
>get at files on CMU's systems without knowing which campus they're
>on).  True?  If so, I'd think this would be much preferable to all the
>"remote mount" junk....
>  For security...something along the lines of Kerberos would be great.

We use AFS+Kerberos at project Athena.  It's now in the almost releasable
state.  There are some changes that need to be made before we can use it
for normal file service.  It should be said that AFS is not a replacement
for NFS.

Ways in which AFS wins:

	Performance: it keeps a local cache of recently accessed files
		(this cache is not destroyed by reboot), so performance
		is much better.

	Transparency: there is no need to explicitly mount a filesystem.
		Directories can be moved around without the owner knowing
		or caring (important for load-balancing).  I can tell anyone
		to look at athena.mit.edu/mit/jfc/README.afs in his afs
		filesystem, and he will be able to get to it from anywhere
		with a net connection.

	Quota: quota control is per-directory instead of per-filesystem
		(this is an important requirement in our environment,
		since per-user quota doesn't "do the right thing" on
		group-writeable directories).

	Access control: Access control lists per directory, updates are
		instantaneous.  (At Athena the group lists on NFS servers
		are updated no more than daily.)

Ways in which AFS loses:

	Access control: There are per-directory acls, but no way (yet) to
		set permission on an individual file.

	Filesystem format:  You can't export a UNIX filesystem via AFS.
		There isn't any good way to get at AFS files on the same
		machine, except through AFS (which means sending them
		over the network, back to your disk [now in your AFS cache],
		and then reading them).

	Ease of setup:  With our Kerberos authenticated NFS, untrusted
		servers are possible (since each NFS server uses a different
		key to authenticate requests, breaking into one server does
		nothing for the others).  With AFS, all servers share a key
		(so root access to a server is equivalent to root access to
		files on other local servers).  This means you can't add a
		random machine to AFS while maintaining security.

Some of the problems will be fixed over time.  For most of our file service
needs, AFS wins big over NFS.  NFS won't go away, because it is more widely
used (measured by number of sites and number of machine/OS types) and because
it works with a UNIX filesystem, but it will get a lot less use in the future.

    --John Carr (jfc@athena.mit.edu)