J. Bruce Fields wrote:
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"?
The SHOULD you quote:
To avoid this mechanism being used to subvert user and
group translation, so that a client might pass all of the owners and
groups in numeric form, a server SHOULD return an NFS4ERR_BADOWNER
error when there is a valid translation for the user or owner
designated in this way. In that case, the client must use the
appropriate name@domain string and not the special form for
compatibility.
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.
How do you detect the SHOULD?
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.
No, it doesn't. My point is that the SHOULD is hard to enforce. How does
the server
determine that there is a "valid translation"?
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.
I'd say that problem breaks down to being able to correctly configure
your id domain or to
allowing a server which is not connected to NIS/LDAP to be able to
accept random users.
With NFSv3, a server will happily serve up data in these situations.
While various ways pop to mind to hack this up, why not bring it up to
the working group
and get consensus? Perhaps whomever struck down Jim Rees will recall why
it is such
a bad idea and convince us all to stay away from it. Or perhaps after
years of enduring
customers who can't do the above, they will capitulate.
--
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
