Bug 1127924 - "(sec=krb5)" per-client export restriction ignored in /etc/exports
Summary: "(sec=krb5)" per-client export restriction ignored in /etc/exports
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: 19
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-08-07 20:45 UTC by Gregory Lee Bartholomew
Modified: 2014-08-13 20:02 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-08-13 20:02:25 UTC

Attachments (Terms of Use)

Description Gregory Lee Bartholomew 2014-08-07 20:45:06 UTC
Description of problem:

Per the example given in the man page, I expect a <client>(<export options>) paring of the form "*(sec=krb5)" listed in /etc/exports to require krb5 security for the clients that matched the wildcard.

Excerpted from "man 5 exports":
> ... Each listed client may be immediately followed by a parenthesized, comma-separated list of export options for that client. ...
> ...
> # sample /etc/exports file
> ...
> /srv/www -sync,rw server @trusted @external(ro)
> ...
> ... The sixth line exports a directory read-write to the machine 'server' as well as the `@trusted' netgroup, and read-only to netgroup `@external', all three mounts with the `sync' option enabled. ...
> ...


Following are the results of my attempt to export a "test" share with sec=sys:krb5 to the "trusted" client but sec=krb5 to anyone else.

SERVER with *(sec=krb5):

[root@nfs ~]# cat /etc/exports
/export -fsid=0,sec=sys:krb5,ro,no_root_squash *
/export/test -fsid=1,rw,no_root_squash trusted *(sec=krb5)

[root@nfs ~]# exportfs -rv
exporting trusted:/export/test
exporting *:/export/test
exporting *:/export


[root@untrusted ~]# mount nfs.cs.siue.edu:/test /mnt
[root@untrusted ~]# ls /mnt
dir1 dir2 dir3
[root@untrusted ~]# mount
nfs.domain:/test on /mnt type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=XXX.XXX.XXX.XXX,local_lock=none,addr=YYY.YYY.YYY.YYY)

In the above trial run, the "untrusted" client was able to mount the test share without any kerberos credentials.  This is not what I expected and it may be a bug.


Following are the results of removing "*(sec=krb5)" from /etc/exports on the server and remounting the "test" share from the "untrusted" client.  The client is not able to list the contents of the filesystem, as expected.

SERVER without *(sec=krb5):

[root@nfs ~]# cat /etc/exports
/export -fsid=0,sec=sys:krb5,ro,no_root_squash *
/export/test -fsid=1,rw,no_root_squash trusted
[root@nfs ~]# exportfs -rv
exporting trusted:/export/test
exporting *:/export


[root@untrusted ~]# mount nfs.cs.siue.edu:/test /mnt
[root@untrusted ~]# ls /mnt
[root@untrusted ~]# mount
nfs.domain://test on /mnt type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=XXX.XXX.XXX.XXX,local_lock=none,addr=YYY.YYY.YYY.YYY)


[root@nfs ~]# rpm -q nfs-utils


[root@untrusted ~]# rpm -q nfs-utils

Comment 1 J. Bruce Fields 2014-08-13 19:37:26 UTC
Is there a mountpoint at /export/test?  (So, is /export/test on a different filesystem from /export/?  Relevant output from "mount" or "findmnt" on the server side might be interesting.)

Also, contents of the server-side files /proc/net/rpc/*/content might be interesting.

Comment 2 Gregory Lee Bartholomew 2014-08-13 19:53:49 UTC
I've since updated my server to kernel-3.14.15-100.fc19.x86_64 and nfs-utils-1.2.8-6.3.fc19.x86_64.  I'm now getting "mount.nfs: an incorrect mount option was specified" when I run the mount command on the client (I'm not specifying any mount options).

If I add "-o sec=sys" I get "access denied by server ...".
If I add "-o sec=krb5" I get the "an incorrect mount option ..." error.

I guess the bug was particular to the older version of nfs-utils and/or the kernel.

FYI, /export/test was mounted from a zfs filesystem and /export was on the root ext4 filesystem.

Sorry for reporting the bug against an outdated package.  I'll let you close out the bug because I'm not sure how it should be filed.


Comment 3 Gregory Lee Bartholomew 2014-08-13 19:55:28 UTC
P.S. I think the kernel version was kernel-3.11.8-200.fc19.x86_64 when the problem first occurred.


Comment 4 J. Bruce Fields 2014-08-13 20:02:25 UTC
Hm, OK, well, closing, but feel free to reopen or open another bug if needed for the "incorrect mount option" problem.

Note You need to log in before you can comment on or make changes to this bug.