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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sun, 12 May 2019 18:12:14 +0000
Subject: [Bug 203585] Feature Request for filesystems that support
 noexec/exec mount options

--- Comment #2 from Thomas Spear ( ---
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

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