Re: How about just O_EXEC? (was Re: [PATCH v5 3/6] fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC)
From: Florian Weimer <hidden>
Date: 2020-05-18 07:27:00
Also in:
linux-fsdevel, linux-integrity, linux-security-module, lkml
Possibly related (same subject, not in this thread)
- 2020-05-19 · Re: How about just O_EXEC? (was Re: [PATCH v5 3/6] fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC) · Mickaël Salaün <mic@digikod.net>
- 2020-05-19 · Re: How about just O_EXEC? (was Re: [PATCH v5 3/6] fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC) · Aleksa Sarai <hidden>
- 2020-05-15 · Re: How about just O_EXEC? (was Re: [PATCH v5 3/6] fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC) · Mickaël Salaün <mic@digikod.net>
- 2020-05-15 · Re: How about just O_EXEC? (was Re: [PATCH v5 3/6] fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC) · Kees Cook <hidden>
- 2020-05-15 · Re: How about just O_EXEC? (was Re: [PATCH v5 3/6] fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC) · Kees Cook <hidden>
* Kees Cook:
I think I misunderstood what you meant (Mickaël got me sorted out now). If O_EXEC is already meant to be "EXEC and _not_ READ nor WRITE", then yes, this new flag can't be O_EXEC. I was reading the glibc documentation (which treats it as a permission bit flag, not POSIX, which treats it as a complete mode description).
I see. I think this part of the manual is actually very Hurd-specific (before the O_ACCMODE description). I'll see if I can make this clearer in the markup. Thanks, Florian