On Mon, 2013-05-06 at 14:49 +0000, Adamson, Dros wrote:
> On May 6, 2013, at 9:52 AM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
>
> > Hi-
> >
> > On May 6, 2013, at 9:27 AM, Weston Andros Adamson <dros@xxxxxxxxxx> wrote:
> >
> >> Older clients match the 'sec=' mount option flavor against the server's
> >> flavor list (if available) and return EPERM if the specified flavor is not
> >> found. Recent changes would skip this step and allow the vfs mount even
> >> though no operations will succeed.
> >>
> >> Signed-off-by: Weston Andros Adamson <dros@xxxxxxxxxx>
> >> ---
> >>
> >> Hey Chuck,
> >>
> >> This fixes a regression that was introduced with the recent nfs_select_flavor
> >> changes - I'm pretty sure we want to match the specified flavor instead of just
> >> using it.
> >>
> >> Example of the regression:
> >>
> >> the server's /etc/exports:
> >>
> >> /export/krb5 *(sec=krb5,sec=none,rw,no_root_squash)
> >>
> >> old client behavior:
> >>
> >> $ uname -a
> >> Linux one.apikia.fake 3.8.8-202.fc18.x86_64 #1 SMP Wed Apr 17 23:25:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> >> $ sudo mount -v -o sec=sys,vers=3 zero:/export/krb5 /mnt
> >> mount.nfs: timeout set for Sun May 5 17:32:04 2013
> >> mount.nfs: trying text-based options 'sec=sys,vers=3,addr=192.168.100.10'
> >> mount.nfs: prog 100003, trying vers=3, prot=6
> >> mount.nfs: trying 192.168.100.10 prog 100003 vers 3 prot TCP port 2049
> >> mount.nfs: prog 100005, trying vers=3, prot=17
> >> mount.nfs: trying 192.168.100.10 prog 100005 vers 3 prot UDP port 20048
> >> mount.nfs: mount(2): Permission denied
> >> mount.nfs: access denied by server while mounting zero:/export/krb5
> >
> > This is wrong behavior, and is fixed by my patch.
> >
> >> recently changed behavior:
> >>
> >> $ uname -a
> >> Linux one.apikia.fake 3.9.0-testing+ #2 SMP Fri May 3 20:29:32 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
> >> $ sudo mount -v -o sec=sys,vers=3 zero:/export/krb5 /mnt
> >> mount.nfs: timeout set for Sun May 5 17:37:17 2013
> >> mount.nfs: trying text-based options 'sec=sys,vers=3,addr=192.168.100.10'
> >> mount.nfs: prog 100003, trying vers=3, prot=6
> >> mount.nfs: trying 192.168.100.10 prog 100003 vers 3 prot TCP port 2049
> >> mount.nfs: prog 100005, trying vers=3, prot=17
> >> mount.nfs: trying 192.168.100.10 prog 100005 vers 3 prot UDP port 20048
> >> $ ls /mnt
> >> ls: cannot open directory /mnt: Permission denied
> >> $ sudo ls /mnt
> >> ls: cannot open directory /mnt: Permission denied
> >> $ sudo df /mnt
> >> df: ‘/mnt’: Permission denied
> >> df: no file systems processed
> >> $ sudo umount /mnt
> >> $
> >
> > This is correct behavior. The server should map the user's AUTH_SYS credential to anonymous. If anonymous does not have permission on /export/krb5, then the server should prevent its access to the export.
>
> You're talking about AUTH_NULL behavior here, right?
>
> >
> > I assume this is a Linux NFS server. Does the Linux server support sec=none listed in the export options in the same way that NetApp and Oracle Solaris do?
>
>
> So there are two issues here and I think they're getting confused.
>
> The example is of the first issue: mounting a krb5 only export with sec=sys
> - client mounts sec=sys
> - the server list is [krb5]
> - the client completely ignores this list and just uses sys.
> - no operations work, it's a 'dud mount'
>
> The second issue is the AUTH_NULL stuff - lets just ignore that for now.
>
> Are you saying that the client should just use whatever sec= is specified and never try to match against the server list?
>
> A little background - I ran into this implementing a different patch that makes sure v4.x mounts are actually using the specified flavor (if one exists) to mount the export -- that is, it can follow SECINFOs to do initial lookup, but must be using the specified flavor on the export path passed to mount. After the initial mount lookup, SECINFOs will be used normally. Trond thought that this was a bug that should be fixed - that it's wrong when client reports that it's using one flavor (as seen in mount output, etc) when it's really using another. This (other) patch works, but when no version is specified, it always falls back to v3 and the mount will always succeed - even if the auth flavor isn't supported by the export.
In the NFSv4 case, we should definitely be returning EACCES if the user
tries to specify a security flavour that doesn't allow the mount to
succeed, instead of having auto-negotiation override it.
With that in mind, I agree that we should do the same with NFSv3 in
order to avoid the kind of mount failover situation that Dros describes
above. Having the mount 'succeed' yet not actually be usable by anyone
is just wrong (even if that is what we used to do before security
negotiation was added).
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
