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 [EMAIL PROTECTED] 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.
_______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
