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