Yeah, and the thing I think it _totally_ and utterly broken is that there
can be only one of these per process.
I don't see where the 1:1 idea comes from, except from a bad
implementation.
> There is absolutely no connection between userids and PAG's,
> the same way that there is no connection between userids and
> process-numbers. (Roughly speaking:) The 10th person to log
> in will get the 10th pag, no matter what userid they happen
> to log in as.
And this is also again nothing but the result of a bad implementation.
group nigh impossible, since now the joiner (login or something) has to
keep track of what pag's it has used for previous logins. Which is fine as
long as you have _one_ login authority, but it's a total disaster to
require that kind of centralization.
> It's tokens which have some relation to userids. In the world
> of AFS, a pag can hold only one token from any one AFS cell
> at a given time. But I can change which "AFS userid" that I
> am, without changing which pag I am in, and all processes in
> that same pag will instantly become that same "AFS userid".
Yes. And apparently PAG's - as you see them - are nothing but a AFS issue.
As such, I think they are totally uninteresting for the core kernel, and I
will _not_ be applying any patches that introduce such a limiting and
stupid notion into the core kernel.
I'm interested in a much more generic issue of "user credentials", and
here a PAG can be _one_ credential that a user holds on to. But to be
useful, a user has to be able to have multiple such credentials. While one
might be his "AFS userid", another will be his NFS mount credentials, and
a third one will be his key to decrypt his home directory on that machine.
If it's useful for AFS only, I'm not interested.
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/