Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

Linus Torvalds (torvalds@transmeta.com)
Wed, 14 May 2003 21:59:13 -0700 (PDT)


On Wed, 14 May 2003, Russ Allbery wrote:
>
> If a single process is in possession of multiple sets of credentials at
> the same time, how does the file system code in the kernel know which ones
> to use for a given operation with a network file system?

The file system code will have to make up its own mind about it.

In particular, it's likely the case that only _one_ credential is valid
for that particular mount anyway. You have to ask yourself: where did
these keys all _come_ from in the first place? And the answer is: usually
the filesystem. The key was used and registered at mount-time (encrypted
filesystem), or by some filesystem-specific key exchange.

So I expect that for many filesystems there will never be any confusion.
Clearly AFS only expects to have one session PAG, for example (since that
is how the _current_ AFS stuff wants to do it), and that implies that
whenever that session PAG is instantiated, the code that instantiates it
will remove any old stale PAGs.

But the fact that you'd have AFS with just one set of credentials doesn't
mean that the same process might not want to have another PAG for other
uses. Each use might only fit one way.

And even when you have multiple PAG's for the same entity, this is not a
new situation. In fact, UNIX pretty much since day 1 has had it: what do
you think user/group/other are? They are prioritized credentials. There,
you have two different credentials (well, groups are multiple ones in
themselves), with a prioritation scheme ("user matters more, but if user
doesn't match there is no prioritation in groups _except_ one group entry
is special in that we'll use that for new ID creation").

Up to the filesystem to decide what it does with the different
credentials, in other words. Some filesystem may decide to only allow one.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/