Linux – Permission denied for symlink to executable in nfs mounted directory with the sticky bit enabled

I'm not exactly sure from your question what is being shared from where, but my work's Samba share may be a similar situation. I've got Samba users work, chris, and wendy.

We've got a Debian server with a 4TB raid. I've got it set up so there is a general "work" username/password we all know. The raid's permissions work well for the Windows people, but I recall having to go clean up write permissions (via changing ownership) so that Windows users could edit my Linux login's work.

See my answer here: Linux user cannot read or edit outside their home directory where I talk about using the sticky bits for owner and group permissions.

Here's my raid's perms:

/raid$ ls -alh
total 33M
drwxrwsr-x.  46 work     users 4.0K Jan  7 18:33 .
drwxr-xr-x   24 root     root  4.0K Jan  4 16:13 ..
-rwxr--r--    1 wendy    users  12K Dec 31 16:57 boc.pfl
drwxrwsr-x.   7 work     users 4.0K Aug 15  2009 catalog
drwx--S--T.  43 chris    users  12K Jan  5 16:53 chris
drwxrwsr-x.   6 work     users 4.0K Dec 31 16:32 dealers
drwxrwsr-x    3 work     users 4.0K Nov  5 17:51 Distributors
drwxrwsr-x.  22 work     users 4.0K Dec 29 16:58 docs
drwx--S--T.   9 wendy    users 4.0K Jan  3 18:40 wendy
drwx------   17 work     users 4.0K Sep  8  2011 work

And I think I see what I need to research to answer my own Linux vs Windows user, the S on directories. This will have to get looked at the next time I can get away from Windows and can turn on my linux desktop again.

If you snoop around my SU or SO profiles, I'm pretty sure I've talked about all this more...

The most likely reason you are having problems with non-root mounts is the "secure" export option, which is on by default. It disallows mount requests that come in with a source port greater than 1024. On most systems, binding to a port less than 1024 requires root access, so this is a fairly decent way of ensuring the mount was made by root.

The issue, as explained in the README for my NfSpy penetration testing tool, is that the NFS protocol (versions 2, 3, and even 4, without proper configuration) completely trusts the user ID sent in requests from client machines. By limiting requests to only those made by root, you limit your trust to only users on the client machine who have root access. Without this setting (using "insecure" in your exports file), any user can claim to have any UID and access any file on the export.

The reason it is working on Linux is probably because /bin/mount is setuid root:

~$ ls -l /bin/mount
-rwsr-xr-x 1 root root 72188 2011-01-20 13:54 /bin/mount

Just a hunch, but check the permissions on the mount binary on your FreeBSD system. If it is setuid, then you still have a problem, and I don't know what it is. If not, then that would explain what's going on.

Good luck with this, but please consider the security implications of allowing any user on a system to access any file on your server. I recommend using NFS4 with GSS authentication mechanisms instead of the traditional AUTH_SYS flavor.