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,[email protected],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.
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,[email protected],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