Chuck Lever wrote:
On Aug 13, 2010, at 12:31 PM, J. Bruce Fields wrote:
On Fri, Aug 13, 2010 at 10:43:06AM -0400, Steve Dickson wrote:
On 08/11/2010 07:22 PM, Neil Brown wrote:
I agree. And surely it can all be solved in idmapd.
On the server, tell idmapd to map all users to "NUMERIC_USER:%d" and all
groups to "NUMERIC_GROUP:%d" (or whatever) for some given clients (i.e. stop
ignoring the 'authentication name'. And of course map those names back to
numbers.
I don't know if the client can easily differentiate based on which server it
is talking to, but there is probably less need there (and maybe it can
anyway).
It shouldn't take more that half an hour to hack something into
idmapd.c:nfsdcb() for the server side and nfscb for the client side - or
for a quicker hack, just go directly to imconv and ignore the client name on
the server. (all this in nfs-utils of course).
I took a look... and you are right it would not be that difficult to
hack something up... but would this only be a Linux to Linux thing?
Or am I missing something?
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?
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?
Or do we have to send uid 2525 to our id mapper to see if a reverse
mapping applies?
What if there exists a thud@remote with that uid, but the mapping was
really bfields@crimson?
We could claim it was a violation, which is why we would want the client
to provide the
string and not the uid.
Is this something that should be taken up in 3530bis?
The issue should at least be presented on the working group alias.
I suppose we could make this all configurable, and then argue about what
the defaults should be. If we implement all this in idmapd then that's
easy.
I don't know what other clients and servers do. Probably 1 and 2 at
least, but maybe it's something to check at the next bakeathon.
Do we actually use an @-less "nobody" as suggested in the last
paragraph? If not that might be something else to fix.
--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
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
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
--
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
