You could just define it in the first write to the auth file. In any
case, there wouldn't
be any need for the names in Tauth and Tattach to match, because the
server would
always use the result of the authentication.
I imagine the intention was that in Tauth, uname defined the user to
authenticate within
the space defined by the given aname (if relevant), and only that
uname (in that aname context)
would be authenticated; consequently it was reasonable to use the
resulting afid to authenticate
one or more matching Tattach requests. Thus the (uname, aname) on
Tauth should really be
constraining the initial state for authentication on the auth file
(ie, on success, it's taken to have
authenticated that uname). For instance, in the p9any case in
role=server, it should also be given user=uname,
and with p9sk1, only uname would be acceptable as {uid sub C}. Then
all the IDs involved would match.
(That doesn't preclude some sort of user name mapping, as is already
done for instance by fossil,
or a map of the name to an internal user ID as done by kfs.)
Note that on a shared server, with several unames actively accessing a
shared file server connection,
the users are trusting the server not to cheat with fids (ie, allow
one user to attach a fid,
however that's done, and then make that fid usable by another user by
accident, or to a miscreant by design).
On 10 October 2011 21:47, Yaroslav <[email protected]> wrote:
> Uname in Tauth/Tattach indeed seem to be irrelevant for p9any but as
> it is external to 9P this may be a provision for other possible auth
> schemes where the uname may be the only place to provide an indentity
> being authenticated...
>
>
