| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Sun, 12 May 2019 18:12:14 +0000 From: bugzilla-daemon@...zilla.kernel.org To: linux-ext4@...r.kernel.org Subject: [Bug 203585] Feature Request for filesystems that support noexec/exec mount options https://bugzilla.kernel.org/show_bug.cgi?id=203585 --- Comment #2 from Thomas Spear (Speeddymon@...il.com) --- 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. -- You are receiving this mail because: You are watching the assignee of the bug.
Powered by blists - more mailing lists