|
Message-ID: <a7345fd6-ec2b-ac24-842d-8cded56df958@digikod.net> Date: Thu, 30 Apr 2020 12:45:38 +0200 From: Mickaël Salaün <mic@...ikod.net> To: Christian Brauner <christian.brauner@...ntu.com>, Aleksa Sarai <cyphar@...har.com> Cc: linux-kernel@...r.kernel.org, Alexei Starovoitov <ast@...nel.org>, Al Viro <viro@...iv.linux.org.uk>, Andy Lutomirski <luto@...nel.org>, Christian Heimes <christian@...hon.org>, Daniel Borkmann <daniel@...earbox.net>, Deven Bowers <deven.desai@...ux.microsoft.com>, Eric Chiang <ericchiang@...gle.com>, Florian Weimer <fweimer@...hat.com>, James Morris <jmorris@...ei.org>, Jan Kara <jack@...e.cz>, Jann Horn <jannh@...gle.com>, Jonathan Corbet <corbet@....net>, Kees Cook <keescook@...omium.org>, Matthew Garrett <mjg59@...gle.com>, Matthew Wilcox <willy@...radead.org>, Michael Kerrisk <mtk.manpages@...il.com>, Mickaël Salaün <mickael.salaun@....gouv.fr>, Mimi Zohar <zohar@...ux.ibm.com>, Philippe Trébuchet <philippe.trebuchet@....gouv.fr>, Scott Shell <scottsh@...rosoft.com>, Sean Christopherson <sean.j.christopherson@...el.com>, Shuah Khan <shuah@...nel.org>, Steve Dower <steve.dower@...hon.org>, Steve Grubb <sgrubb@...hat.com>, Thibaut Sautereau <thibaut.sautereau@....gouv.fr>, Vincent Strubel <vincent.strubel@....gouv.fr>, kernel-hardening@...ts.openwall.com, linux-api@...r.kernel.org, linux-security-module@...r.kernel.org, linux-fsdevel@...r.kernel.org Subject: Re: [PATCH v3 0/5] Add support for RESOLVE_MAYEXEC On 30/04/2020 10:07, Christian Brauner wrote: > On Thu, Apr 30, 2020 at 11:54:29AM +1000, Aleksa Sarai wrote: >> On 2020-04-28, Mickaël Salaün <mic@...ikod.net> wrote: >>> The goal of this patch series is to enable to control script execution >>> with interpreters help. A new RESOLVE_MAYEXEC flag, usable through >>> openat2(2), is added to enable userspace script interpreter to delegate >>> to the kernel (and thus the system security policy) the permission to >>> interpret/execute scripts or other files containing what can be seen as >>> commands. >>> >>> This third patch series mainly differ from the previous one by relying >>> on the new openat2(2) system call to get rid of the undefined behavior >>> of the open(2) flags. Thus, the previous O_MAYEXEC flag is now replaced >>> with the new RESOLVE_MAYEXEC flag and benefits from the openat2(2) >>> strict check of this kind of flags. >> >> My only strong upfront objection is with this being a RESOLVE_ flag. >> >> RESOLVE_ flags have a specific meaning (they generally apply to all >> components, and affect the rules of path resolution). RESOLVE_MAYEXEC >> does neither of these things and so seems out of place among the other >> RESOLVE_ flags. >> >> I would argue this should be an O_ flag, but not supported for the > > I agree. OK, I'll switch back to O_MAYEXEC.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.