On Jul 10, 2009, at 4:55 PM, Tom Haynes wrote:
Chuck Lever wrote:
If mountd does not provide AUTH_SYS a mount request with no sec=
will fail. Should it try the first one in the list instead? What
if the first one is AUTH_NULL?
In other words, I'm not sure what is the right behavior here. What
it does now is probably suboptimal. I've browsed 2623 a bit, but
it's not hitting me.
So we (OpenSolaris) changed our behavior inadvertently to do the
list in order. Which means we are trying AUTH_NONE against
a Linux server. (Bug is here: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6834430)
We are considering two changes:
1) Use our default flavor (user configurable)
2) Order the list by strength based on the flavors we support.
The first option would get us to where you are going to be. AUTH_SYS
will
probably be the default.
It's easy to implement, test, and explain in a man page. I think the
first option gives the least surprise (ie a negotiated result that is
not what you expect and thus may expose your data).
The second option would push AUTH_NONE to the end of the list, which
corresponds to my thinking of it as a wild card.
The problem with the server's auth list is that it is a list of _all_
flavors that the server supports. That doesn't mean the client
necessarily wants to use any of those by default, especially not
AUTH_NONE. We've hit a number of behavior bugs where the client is
negotiating AUTH_NONE and users can see their files, but not update
them, and no real explanation why. Very confusing.
It might be better to have a subset of flavors that the client can
negotiate, like AUTH_SYS and AUTH_GSS/Krb5. The others are supported,
but can't be used unless the client's administrator has explicitly
asked for them. Having a default of only AUTH_SYS is rather a
degenerate case of this.
But it also means that if AUTH_SYS is not our default, then we might
try
Kerberized access first. I think that is a surprise.
Also, if the server has already ordered the list based on the
preference it
would like the client to try, then the client should honor that list
if no
specific flavor is used.
I was wondering when a server would not want to order the flavor list
by strongest to weakest. We have the use case of the kerberos 5
pseudoflavors: clients should probably use krb5 over krb5p by
default, as this provides good security without a lot of performance
overhead. But krb5p is stronger security than krb5.
So, I would say algorithmically:
1) If the client specifies a flavor, it uses that if the server
supports it. If the
server does not, the mount fails.
2) If the client has a default, it tries that first if the server
supports it. If the
server does not, then:
3) The client walks the array of flavors and uses the first that it
supports
and the server supports.
I think it would be polite to display a warning if step 3 gives you
AUTH_NONE.
--
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
