Prevent root from deleting files on network mounts
Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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?
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 )
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.
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.
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.
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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.