Greetings, I want to ask for a new mount flag to be considered which enhances the noexec/exec flag for filesystems that support those flags. What I would like to do is to designate in /etc/fstab that a filesystem with either flag can be bypassed by certain users. For example, there is a web app that insists on writing a file to the root of /tmp, (a shared object library) in order to then load that file into memory to perform some operation. Why it is done this way, I don't know, but we have /tmp set to noexec for security reasons. The app is required to be able to execute the file in order to load it into memory it seems, because the app fails when we have noexec flag set on the /tmp filesystem, and it works fine without that flag. So, I was hoping that in the future, we might be able to work around this dilemma by having a "exec_users=/noexec_users=" type mount option. Where, if a filesystem has "noexec", you could do: "noexec,exec_user=john", and conversely if a filesystem has "exec" and you want to lock down a certain user/set of users, you could do "exec,noexec_user=paul" If this is considered useful enough, and is able to be implemented without much fuss -- BTW I'm HOPING that since the kernel does permissions checks for file/directory access, it can also do those checks for noexec/exec access -- then could you please also extend the mount options to have group_noexec/group_exec flags as well?
This is not at all trivial to implement, for a number of reasons: *) The kernel doesn't have access to the username to uid map. It might be in /etc/passwd; but you might also be using LDAP or Yellow Pages for the username->uid map. This could done by adding support for this to each file system which implements this feature request's /sbin/mount.FSTYP, but... *) This also begs the question of how to handle user namespaces. The simplest way of solving this problem may be to change the web application to write its temporary file in some other directory, and let that directory be writable only by the web application's user id, and let that directory be mounted without the noexec flag. If you are using tmpfs, you can mount multiple tmpfs instances, and create a special one which has mount options just for that web application, with an fstab entry like this: tmpfs /run/user/1042 tmpfs rw,nosuid,nodev,relatime,size=2048k,mode=700,uid=1042,gid=1042 0 0
Thanks for updating so quickly. An acceptable workaround for the uid mapping would be to just list the uids in the fstab. I appreciate the suggestion to modify the web app, and yes it would be great if we could. Unfortunately its a 3rd party app with vendor support, and its hard coded to write to the root of /tmp -- we can't even get it to write to a folder, though I am considering suggesting a chrooted environment for the app so that we can virtualize the access to /tmp that way. I saw mention of getting around it by using bind mounts over on stack overflow, but that would also require the ability to make it write somewhere other than /tmp. The app team is trying to push for acceptance of the risk of removing noexec from /tmp (RHEL7 defaults to noexec for /tmp so its a change to the current policy), but everything I've ever understood about /tmp being world writable tells me that noexec on /tmp is a sane default and should be left that way. Anyways, I could see having noexec_user= for exec filesystems being useful in a variety of circumstances, but the rest of the request is a bit niche, so I don't guess it would get much support from the community. Thanks again for the help.