On Mon, 2009-07-13 at 11:07 -0500, Tom Haynes wrote:
> Trond Myklebust wrote:
> > On Fri, 2009-07-10 at 17:38 -0500, Tom Haynes wrote:
> >
> >> If they have the same access lists, then the server is free to order them...
> >>
> >> share -F nfs -o sec=sys:none:krb5,rw /foo
> >> share -F nfs -o sec=sys,ro,sec=krb5p,rw,root=@xxxxxxxxxxx,sec=krb5,rw /bar
> >>
> >> In the first, we don't care how the server presents them. In the second,
> >> the list would be: sys krb5p krb5.
> >>
> >
> > Meaning that the client defaults to read-only access?
> >
> > Trond
> >
>
> In this scenario, yes.
>
> The export states that if you can't be bothered to run kerberos, I can't
> be bothered to let you write
> to my filesystem.
Well, how does the security negotiating NFSv3 client discover that?
I'm assuming that in the case of NFSv4, you would return
NFS4ERR_WRONGSEC if the user attempts to write to the server, but what
do you do in the case of NFSv3? Do you return an rpc level AUTH_TOOWEAK
error instead?
Trond
--
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
