How to restrict nfs share to specific user(s)?

Hi,

My openSUSE 13.2 desktop is also a nfs server on my home LAN. Until recently the shared directories contained only media. A WDTV box is part of the LAN and access the media files on the server, as nobody IINM (it doesn’t have a username/password).

I’ve set a number of non-media shares on the server for backing up to two other boxes (openSUSE 13.2/42.1) in the LAN. These openSUSE boxes run under the same username of the server.

The problem is that the new shares appear mixed with the shared media folders in the WDTV box, evoking complaints from the wife…

I’d like to restrict them to the oS boxes only, but I couldn’t find out how to specify users in man mount nor in man nfs, and I’d prefer not to change the non-media folders standard permissions on the server box. How can I fix this?

Thank you, and a happy new year.

It is impossible to restrict mounting of NFS exported directory based on user name (for a start, all mounting happens as root; at the time of mounting there is no information which user is going to access it). You can only use usual access control mechanism on NFS server to limit access to files.

If your media server supports CIFS/SMB, you may consider using it.

Unix/Linux access to files is by ownership (user, group, others) and the permissions allowed to them (read, write, execute/inode-access). There is no special mechanism on the level of mounted file systems. The whole idea of “mounting” is to present one tree of directories/files, starting at / to the user. The user in fact should not “know” anything about where the tree crosses file system boundaries.

Normally a user is owner of (and can thus access files in) a home directory. That is the place (s)he would expect to find his/her data and be able to access it. And be able to protect it from others by restricting permissions. It is however not uncommon to have other branches in the directory tree also owned by a particular user. As long as the path leading to such a branch allows access in the same way that the path up to her/his home directory allows access to the home directory (that is minimal r-x for that user, which mostly leads to what /home has: root:root as owners and rwxr-xr-x), (s)he can work there in the same way as in his home.

Thus, if you want a mounted file system (irrespective if that is NFS or not) to be owned (and thus accessable) by a user, you should let the mount point owned by that user and set access for him in the path leading up to it to r-x for him/her.
E.g. check that /mnt is owned by root:root and has rwxr-xr-x (same as /home) and create /mnt/agnes-data with owner agnes:users and rwxr-xr-x (or more restrictive for others and group, but agnes can change that herself). Use it is mount point (or not) and agnes can work there in the same way as in her home directory. She could even make it easier for herself by creating a symbolic link from her ~/my-other-data /mnt/agnes-data and thus “see” that data on the mount point from within her home directory.

One important thing though. The above assigns space to agnes to create files on it. Those newly created files are then by default owned by agnes:users. When there are already files on the mounted file system, they better be also owned by agnes, or agnes will be restricted in using them by the permission of those files for group and others. That is again the same as for every file everywhere, but notmaly you will not often find a file owned by peter withing agnes home directory. Mounting an existing file system with existing files could create such situations.

BTW, mounting at /mnt/agnes-data and then having the symbolic link created by agnes, is one way of doing this. Alternative you could mount directly on /home/agnes/my-other-data, but many administrators prefer the mount in /mnt/… (or /data/… or the like) for several reasons.

Important in the above is that you master the ideas:

  • there is but one directory tree (starting at /) where all directories and files are situated in (contrary to Windows where every container has it’s own tree like A:/, B:/, etc.);
  • that tree maybe build from more the one file system, but that is in the majority of cases transparent to the end-user;
  • NFS mounts are no different in their end effect to other mounts, that is they are transparent to the end-user;
  • permissions are independent from mounts, file systems, etc., there is ownership (by uid and gid) and there are permissions (r, w, x for u, g. o).

The above needs some amendments when using non-Linux file systems, because they do not have the ownership and permissions connected to them. These are faked on mount and that can lead to some surprises when one does not understand the restrictions connected to the faking.

Much of what was explained above I’ve already gathered from the man pages and usage during the not-so-few years managing this home server, but thanks for the refresh, it was helpful.

So the solution could simply be to deny read permission to the others group, for example change the permissions of folder I don’t want to appear in the WDTV box from something like drwxr-xr-x to drwxr-x–x. This would probably have little or no impact on access to the changed folders by the other CPUs, as they use the same user#/group.

Changed a test folder permissions to drwxr-x–x

Result: files accessible on other CPUs (OK), and not accessible on WDTV (OK), but folders still visible in WDTV media listing (NOT OK).

Changed the test folder permissions to drwxr-x—

Same result. I’d expect that removing the directory execute permission for group other would make the WDTV box not see the folder.

What am I doing wrong?

Note: folder owner is the normal user/group.

You could create another group other than users, make yourself as member of that new group, and chown the permissions to your-user-name:new-group. Any that you want to give access to would have to be added to that group, though.

Note groups are additive ie a user can be a member of multiple groups allowing them permission to do any thing those groups allow.

If you set permissions for a group on a directory then you can block any that do no have permissions from that directory. Setting directory permission to 700 allows the owner to do anything but blocks others from even listing

For example look at permissions for /root only root itself can even list the directory

Setting directory to 770 allows the owner and any member of the group owning the directory to do all things but blocks any other user that is not a member of the group from even listing

Please show actual listing of directory structure, permissions and tell, what files or directories in this structure should be hidden. Otherwise it is impossible to guess what you are trying to do.

I strongly support this. Your story above is not understandable for me. We need everything you might think important and also that you might think unimportant. Listings from .etc/passwd, /etc/group, for every file and directory you use the ls -l, what you try, etc.

One thing I can say though, normally for directories the r and x bits are either set or unset in one of the groupings. I do not understand what you try to achieve with --x for others on a directory.

Same here. Details would go a long way to helping us help you.

Hi.

Sorry you guys found it confusing. I’ll see if I can set a simpler test case during the weekend, preferably removing the WDTV box from the equation (it’s implementation of NFS may be flaky), and see how it goes.

I’ll post the results here, if any. Thanks to all that tried to help.

P.S.: re. posting /etc/passwd, isn’t that risky? Anyway, user entry there AFAIK is the standard stuff:

*user*:x:1000:100:*full_user_name*:/home/*user*:/bin/bash

and

> cat /etc/passwd | grep nfs
statd:x:*nnn*:*nnnnn*:NFS statd daemon:/var/lib/nfs:/sbin/nologin

All other entries are for other unrelated (AFAIK, of course) services.