From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Mon, 10 Oct 2011 23:03:31 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] p9any auth in u9fs: uid value in ticked is ignored Topicbox-Message-UUID: 35e984a4-ead7-11e9-9d60-3106f5b1d025 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 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... > >