[OpenAFS] OpenAFS speed - some benchmarks

John Rudd jrudd@ucsc.edu
Thu, 26 Jun 2003 10:51:47 -0700


On Thursday, Jun 26, 2003, at 09:41 US/Pacific, Jim Rees wrote:

>
>   (I'm hoping it will be per-transaction and not per-mount, as the 
> latter
>   would greatly suck ... yet, it's my understanding that the latter is
>   exactly how previous kerberized nfs's have worked)
>
> I don't know what you mean by this.  The translation is per auth 
> method.
> Auth methods can change at any point, although I would expect a 
> sensible
> server would use a single auth method for all its files.
>

Well, first, let me state that I have never actually used kerberized 
NFS, I've only heard war stories.

What I was told (or, rather, what I inferred from what I was told) was 
that the old (mid 90's vintage) kerberized NFS only did the kerberos 
authentication at mount time.  When you request the mount, the server 
checked that the principle was authorized to mount that file system.  
But once mounted, kerberos, and the principle in question, didn't play 
much of a part.

If Joe@REALM mounts /foo/bar, and he's uid 2002, then at mount time the 
ticket matters.  But during the session, Jim, who doesn't have tickets 
at all, can cd into /foo/bar and use it with his uid 2005.  At that 
point, the session is exactly like normal nfs3, based upon the uid's of 
the processes that are doing the transactions.

And, of course, that's easily subverted.  Jim can break root on the 
client, then su to uid 2002, and access all of Joe's files in /foo/bar 
... without ever duplicating Joe's authentication.  The kerberos part 
only mattered at mount time.


With AFS, your token doesn't only matter when you initiate contact with 
a cell, it matters for each and every transaction (opening files, 
writing to files, etc.).

That's what I was talking about.  I'm hoping that NFSv4 is more like 
the latter and less like the former.