Unable to mount NFSv4 shares due to Yama

[Ynot]

Server
Ubuntu Lucid server

Client
Ubuntu Maverick desktop

When trying to mount NFS shares provided by server, client reports:
mount.nfs4: access denied by server while mounting tony-server:/music

Client Syslog reports:
tony-desktop kernel: [13626.397677] non-matching-uid symlink following attempted in sticky world-writable directory by mount.nfs4 (fsuid 0 != 1000)

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: nfs-common 1:1.2.2-1ubuntu1
ProcVersionSignature: Ubuntu 2.6.35-7.12-generic 2.6.35-rc4
Uname: Linux 2.6.35-7-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Mon Jul 12 00:15:28 2010
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
ProcEnviron:
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: nfs-utils

[Ynot (tatkinson321)]

Solved by trial & error
(this always happens with bugs I file)

Linux 2.6.35 changes how symlinks (and presumably bind mounts) work
detailed here
http://lkml.org/lkml/2010/5/30/144

Solution
change owner of my server's /nfs4exports directory from root to the primary user (UID 1000)

Bug still stands (IMO anyway), as a working config on systems up to and including Lucid is no longer valid under Maverick

[Steve Langasek (vorlon)]

This is an issue with the Ubuntu kernel then, not with nfs-utils; reassigning. It's also not present in the upstream kernel, so marking that task invalid.

[Ynot (tatkinson321)]

Came across this as well
http://lwn.net/Articles/393012/

[Kees Cook (kees)]

This is a bit strange -- are any of those directories sticky? And where is a symlink involved? Can you attach your client's /etc/fstab and the "ls -lad" output of the destination mount points?

[Ynot (tatkinson321)]

ls -lad done on client share mountpoints (NFS shares mounted)

[Ynot (tatkinson321)]

oops,
missed one ls -lad

drwxr-xr-x 18 tony tony 4096 2010-05-07 01:53 /home/tony/scripts/

[Kees Cook (kees)]

Can you show the output of:

  ls -lad /home /home/tony /media /media/raid5

Something in these paths must be sticky (when, in theory, it should not be).

[Ynot (tatkinson321)]

What exactly do you mean by "sticky"?

drwxr-xr-x 5 root root 4096 2009-10-20 02:18 /home
drwxr--r-- 181 tony tony 16384 2010-07-13 12:27 /home/tony
drwxr-xr-x 6 root root 4096 2010-06-29 04:01 /media
drwxr-xr-x 7 root root 4096 2010-06-29 04:02 /media/raid5

[Kees Cook (kees)]

The warning you saw "non-matching-uid symlink following attempted in sticky world-writable directory by mount.nfs4 (fsuid 0 != 1000)" should only happen in the case where a symlink is being following in a directory that is world-writable and sticky ("+t"). None of your directories seem to have that, though.

[Kees Cook (kees)]

Is your server running Maverick too? What does "showmount -e tony-server" show from the client? And what are the contents of tony-server's /etc/exports file?

[Ynot (tatkinson321)]

Server is Lucid
only my desktop is maverick

[Kees Cook (kees)]

And on the server, what does "ls -lda /nfs4exports" show? I think that's the only thing left I haven't checked. NFSv4's namespace semantics are different from older NFS, so I hadn't considered asking about that yet.

[Ynot (tatkinson321)]

drwxrwxrwt 9 tony tony 4096 2010-06-29 03:58 /nfs4exports

I see a 't' at the end of that
this the sticky bit?

[Ynot (tatkinson321)]

It's been years since I set the NFS up, so I'm a little rusty
but re-reading up on it, seems a root owned export dir with sticky bit combined with the root_squash is a security feature
disallowing client root from having root priv's on the server

setting the top-level export dir as root-owned and sticky is on a fair few NFS howto docs around the web

[Kees Cook (kees)]

Yeah, that's the sticky bit alright. But that NFS mount isn't a symlink, so I think this is a kernel bug regardless. I will try to get this reproduced and a fix tested. I think I know what's wrong, but I'll need to double-check. Thanks for helping me debug this!

[Kees Cook (kees)]

Okay, I've got this locally reproduced now. Followed https://help.ubuntu.com/community/NFSv4Howto except for the maverick client, which needs idmapd started explicitly after editing /etc/default/nfs-common. Once that'd one, and using server bind mount, I get the same errors.

i.e. server filesystem layout is configured as such:

mkdir -p /srv/music
chown 1000:1000 /srv/music
mkdir -p /nfs4exports/music
chmod a+rwx,+t /nfs4exports
mount --bind /srv/music /nfs4exports/music

Now client attempts to mount :/music will fail.

I've tested the following, which fixes the issue:
http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=commitdiff;h=2b8c4f0c59a14e795115b00e9c40dffcbd2ee1a7

Thanks again for the report and helping to debug it!

[Ynot (tatkinson321)]

> Thanks again for the report and helping to debug it!

no problem
glad I could help

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 2.6.35-9.14

---------------
linux (2.6.35-9.14) maverick; urgency=low

  [ Andy Whitcroft ]

  * ubuntu: AUFS -- add BOM and automated update script
  * ubuntu: AUFS -- update to b37c575759dc4535ccc03241c584ad5fe69e3b25

  [ John Johansen ]

  * [Config] Enable DRBD as a module

  [ Kees Cook ]

  * SAUCE: Yama: verify inode is symlink to avoid bind mounts
    - LP: #604407

  [ Leann Ogasawara ]

  * [Config] Disable CONFIG_DRM_VMWGFX (staging driver)
    - LP: #606139
  * [Config] ports: Disable CONFIG_DRM_VMWGFX (staging driver)
    - LP: #606139
  * [Config] Enable CONFIG_DEBUG_STRICT_USER_COPY_CHECKS=y
  * [Config] ports: Enable CONFIG_DEBUG_STRICT_USER_COPY_CHECKS=y

  [ Lee Jones ]

  * Stop ARM boards crashing when CUPS is loaded
    - LP: #601226

  [ Upstream Kernel Changes ]

  * perf probe: Support tracing an entry of array
  * perf probe: Support static and global variables
 -- Leann Ogasawara <email address hidden> Fri, 16 Jul 2010 14:38:17 -0700