linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 203585] New: Feature Request for filesystems that support noexec/exec mount options
Date: Sun, 12 May 2019 17:21:56 +0000	[thread overview]
Message-ID: <bug-203585-13602@https.bugzilla.kernel.org/> (raw)

https://bugzilla.kernel.org/show_bug.cgi?id=203585

            Bug ID: 203585
           Summary: Feature Request for filesystems that support
                    noexec/exec mount options
           Product: File System
           Version: 2.5
    Kernel Version: all
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: ext4
          Assignee: fs_ext4@kernel-bugs.osdl.org
          Reporter: Speeddymon@gmail.com
        Regression: No

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?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

             reply	other threads:[~2019-05-12 17:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-12 17:21 bugzilla-daemon [this message]
2019-05-12 17:46 ` [Bug 203585] Feature Request for filesystems that support noexec/exec mount options bugzilla-daemon
2019-05-12 18:12 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-203585-13602@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).