On Tue, Aug 17, 2010 at 12:46:09PM -0500, Tom Haynes wrote: > Chuck Lever wrote: > >On Aug 13, 2010, at 12:31 PM, J. Bruce Fields wrote: > >>There are four cases where translation can be done: > >> > >> Sending id from server to client (ls, stat, getacl): > >> 1. server uid -> string > >> 2. string -> client uid > >> Sending id from client to server (chown, setacl): > >> 3. client uid -> string > >> 4. string -> client uid > >> > >>Cases 1 and 2 are uncontroversial. Definitely map ascii-fied integers > >>in both of those cases. > >> > >>Case 4 violates the SHOULD on page 47. Which would make case 3 useless > >>if all servers respect that SHOULD. I think we should ignore the SHOULD > >>and implement 3 and 4 too, but Trond may not agree. > > > > So how would that happen? What's the antecedent to "that"? > If we send "2525" and we can locally map uid 2525 to 'bfields", does > that mean the client is > attempting to subvert the normal process? I don't understand what you mean by "subvert the normal process", nor what you see as the threat here. > Or do we have to send uid 2525 to our id mapper to see if a reverse > mapping applies? Checking for a reverse mapping doesn't sound like a good idea to me. > What if there exists a thud@remote with that uid, but the mapping > was really bfields@crimson? In the case of a user upgrading from NFSv3 to NFSv4, that's the behavior they've always had, so presumably they can live with it. I'd prefer to avoid situations where something that previously worked over v3 fails when you upgrade the protocol version. I assume that most users arrive at NFSv4 by an upgrade from a previous version of NFS. So my priorities would be 1) to ensure the NFSv3->NFSv4 upgrade goes smoothly, then 2) to make it easy for users to switch from ids to strings, rather than forcing both at once. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
