-   Linux - Server (
-   -   Prevent root from deleting files on network mounts (

bobwall 08-24-2008 08:59 PM

Prevent root from deleting files on network mounts
Greetings. I've setup Samba to mount home directories for 4 computers in my lab. Each user's home on one of the 4 machines can be mounted onto any of the other ones upon login. What I want is to prevent root from inadvertantly modifying or deleting network files. NFS has a root_squash option. Is it possible with CIFS? I have a feeling this kind of permission would have to be enforced on the server instead of the client like NFS's root_squash.

jschiwal 08-26-2008 07:08 AM

I think that if root on the client has a different password, then the authentication will fail and if the line "map to guest = Bad User" is used in the [Global] section, then the root user on the client will be mapped to guest. If the guest user "nobody" doesn't have write access, then root on the client can't modify files on the server.

Also consider making the share read only listing certain users in the write list.

bobwall 08-26-2008 09:53 AM

Thanks for your response. I tried adding

map to guest = Bad User to [global] and
invalid users = root admin nobody to [homes]

but it doesn't work. I think those options only apply for authentication during mounting, not for later access. I suppose the client passes an authentication token for each access and the server doesn't care whether the original user or root is accessing the share on the client - only that the right authentication token is provided. Therefore, only the client can deny root access. Maybe there's a cifs or generic mount option to disallow root from accessing it?

jschiwal 08-26-2008 02:54 PM

I'm afraid I was able to duplicate your problem. I even tried "invalid users = root" in the share definitions. ( However, root has the same credentials on my two test machines, but the user's credentials were used to mount the share.

It might be because root is a network admin group member with access to all the shares, I don't know for sure; or because CIFS supports Linux permissions and acls and the kernel uses permissions and access controls to determine access, just as if it where a local drive.
I guess for cifs mounts you need to consider the host and mounted shares to be in the same security domain ( I just made up that term )

Maybe someone will have the answer. But in the meantime, you might want to use nfs, or control which hosts are allowed to mount shares on the server based on whether you trust root. In other words, be careful who root is. At least it is a user's share that is effected. Never share a system partition/directory the way some windows users share the C:\ drive. ( The windows users shouldn't either )

Sorry I wasn't more helpful.

jschiwal 08-28-2008 03:46 PM

I wonder if you can have a policy (PolicyKit) that will prevent root on the client from writing to a cifs mount. I'm not adept at using PolKit however. I have been prevented from doing things remotely via ssh after su'ing to root that root locally could do.

This may be a server side solution.

Selinux may also help as well.

IsaacKuo 08-28-2008 04:21 PM

NFS's root_squash option can be enforced by the server, or the client, or both. By default, any entry in /etc/exports is treated by the server as having the "root_squash" option set unless "no_root_squash" is explicitly set.

Anyway, you might want to look into using sshfs instead of either cifs or nfs. It's ridiculously easy to set up on the server side (install openssh-server if not already installed). By default, an sshfs mount is only accessable by the user who mounted it.

The downside is that you can't use /etc/fstab to automount your sshfs mounts, since they are mounted by root. Normally, you'd create an sshfs mount command in ~/.bash_profile, but that's not going to work if you're using it to mount the home directory!

Instead, I think you'd want to create a startup script which mounts the directories with something like this:

modprobe fuse
su -c "sshfs bob@server1:/home/bob /home/bob" bob
su -c "sshfs joe@server2:/home/joe /home/joe" joe
su -c "sshfs dan@server2:/home/dan /home/dan" dan

However, I don't really know if this will really work. While each user will be able to access the files in his home directory, no other user will be able to access those files--including any daemons run by root. This may prevent many GUI programs from running.

bobwall 08-28-2008 04:34 PM

Thanks for the suggestion. sshfs will be less work to setup than samba and I know you can auto mount them with pam-mount, which I currently use for the cifs home directories. Does anyone know about the performance? I anticipate users using kde or gnome sessions so it needs to handle a large # open files, which I'm afraid will suffer with sshfs.

jschiwal 08-28-2008 05:45 PM

If you are mounting user's home directories, I would use nfs. A cifs mount might cache files, such as when you want to play media. It does support permissions and facls but you I don't think that all flavors of locking are supported.

sshfs is very convenient, but the encryption slows things down to 3-6MB/s.

bobwall 08-28-2008 06:16 PM

Now that I think about it, I suppose NFS would be a better choice. The main 2 reasons I chose CIFS was it allows mounting from Windows (value overestimated) and the assumption it was more robust security wise than NFS. The extra cost of using CIFS is that I have to maintain a separate Windows account in the LDAP user database, but users can change both their Unix and Windows password with smbpasswd. Also, I suppose nfsd is more lightweight than smbd. I've heard the NFS inadequate security myth, but I care more about integrity than confidentiality - we're in an academic environment.

IsaacKuo 08-28-2008 07:31 PM

Regardless of what file system you use, I think that basic problem remains. If you do things so that root doesn't have access to a user's home directory files, then I think many graphical applications will break. I'm not sure, but maybe neither GNOME nor KDE will function quite right.

All times are GMT -5. The time now is 12:40 AM.