Bug 203585
Summary: | Feature Request for filesystems that support noexec/exec mount options | ||
---|---|---|---|
Product: | File System | Reporter: | Thomas Spear (Speeddymon) |
Component: | ext4 | Assignee: | fs_ext4 (fs_ext4) |
Status: | RESOLVED WILL_NOT_FIX | ||
Severity: | enhancement | CC: | tytso |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | all | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
Thomas Spear
2019-05-12 17:21:56 UTC
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. |