Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am very new to NFS. I would like to make sure I am clear.

If the NFS server shares a directory rw,, and all the files in the directory are permissions 700 and user/group for those files is root/root,,,

On the client you would have to log in as root to see it. Is this correct?

I am aware that a non root user on the client could make a direct connection to override this. (as in don't use the mount, just use an NFS client hack.)

It really seems like anyone who has access to the client machine should have access to the files and that the client machine should be ignoring permissions. Only the server should handle permissions.

Am I correct in my understanding? Is it normal to have this type of layout? Is there a way to ignore the permissions on the client side?

share|improve this question
    
Clean way to do what? Are you trying to have the client ignore permissions? –  JOTN Dec 28 '10 at 21:20
    
Sorry, I updated my question. –  George Bailey Dec 28 '10 at 21:34
add comment

3 Answers

up vote 2 down vote accepted

I would say that overall you are correct in understanding of NFS. Here are some details about the points that you mentioned:

An NFSv3 server only provides the file ownership and access permissions. It's up to the client to enforce those permissions for specific users (i.e. when a process with a specific UID is requesting and fs operation).

Even if you setup NFSv4 with encryption, Kerberos authorization, and LDAP (and Krb and LDAP servers are running of a different host) then the client's root will still have the potential for at least as much fs privileges as all the allowed users and groups. But you could get protection again non-root user activity and even other hosts on the private network.

Normally clients will be very successful at enforce the user permissions. I'm not aware of any simple method to have the file permission ignores for an NFS mount. If that's what you want then simply set the permissions to u=rwx,g=rwx,o=rwx for all folders and u=rw,g=rw,o=rw for all files.

Off topic:

But be careful not to flip the setuid bit - that can actually end-up giving a root shell to regular users (e.g. www-data) on your client. Setuid can be disable completely with the "-o nosuid" option for NFS and non-NFS mounts.

There is a way to disable/enable rootsquash for the Solaris sever (it's called something other than rootsquash in the Solaris terminology - I forgot what it was).

You can have the Solaris server mark the entire share as read only, e.g.:

zfs set sharenfs="ro=@10.20.0.0/16" tank/home/tabriz

Then no matter what the client does, the fs will not be writable.

It's probably not possible for a non-root user on your client to open a direct connection to the NFS server even if the the program can talk the NFS protocol. This is because the NFS client is usually forced to connect form privileged ports and on healthy clients only root can do that.

share|improve this answer
add comment

Sharing the directory rw says that the server should allow anyone with suitable credentials to have read and write access to the directory and it's contents.

By changing the permissions on the directory and it's contents to 700 and the ownership to root/root you then effectively deny access to everyone. This is because by default the Solaris NFS maps the root user from client machines to nobody.

You can find the man page for Solars share_nfs here

share|improve this answer
add comment

NFS security is enforced on the client.

NFS was created back in the day when anybody who would be connecting to the NFS share was within a trusted network. You really should not use NFS if there are any untrusted entities which may be able to send packets to the NFS service.

With that out of the way, NFS will usually default to rootsquash, which means that root on the client (uid 0) is interpreted as nobody (uid 65535) on the server.

Files on disk aren't really associated with a user (this is a general rule, not specific to NFS). They are associated with a uid. If the user alice has uid 100 on the NFS server and user bob has uid 100 on the NFS client then bob will be able to access alice's files. In fact, on the client all files will display as though they are owned by bob. That is, the NFS server merely presents raw metadata to the client. It's up to the client to interpret that however it sees fit.

NFS was not designed for security. Never use NFS on a network where there are untrusted parties.

share|improve this answer
1  
I would agree to that for only NFSv3 and earlier. NFSv4 was a major revamp to modernize security. –  JOTN Dec 28 '10 at 21:57
    
Actually I am not interested in securing NFS. Just in using nfs for the automount and /home features. –  George Bailey Dec 28 '10 at 22:17
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.