Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 6 Sep 2019 19:24:25 +0200
From: Mickaël Salaün <>
To: Christian Brauner <>, Aleksa Sarai
CC: Florian Weimer <>, Mickaël Salaün
	<>, <>, Alexei Starovoitov
	<>, Al Viro <>, Andy Lutomirski
	<>, Christian Heimes <>, Daniel Borkmann
	<>, Eric Chiang <>, James Morris
	<>, Jan Kara <>, Jann Horn <>,
	Jonathan Corbet <>, Kees Cook <>, Matthew
 Garrett <>, Matthew Wilcox <>, Michael
 Kerrisk <>, Mimi Zohar <>,
	Philippe Trébuchet <>, Scott
 Shell <>, Sean Christopherson
	<>, Shuah Khan <>, Song Liu
	<>, Steve Dower <>, Steve Grubb
	<>, Thibaut Sautereau <>,
	Vincent Strubel <>, Yves-Alexis Perez
	<>, <>,
	<>, <>,
Subject: Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on

On 06/09/2019 19:20, Christian Brauner wrote:
> On Sat, Sep 07, 2019 at 03:07:39AM +1000, Aleksa Sarai wrote:
>> On 2019-09-06, Mickaël Salaün <> wrote:
>>> On 06/09/2019 17:56, Florian Weimer wrote:
>>>> Let's assume I want to add support for this to the glibc dynamic loader,
>>>> while still being able to run on older kernels.
>>>> Is it safe to try the open call first, with O_MAYEXEC, and if that fails
>>>> with EINVAL, try again without O_MAYEXEC?
>>> The kernel ignore unknown open(2) flags, so yes, it is safe even for
>>> older kernel to use O_MAYEXEC.
>> Depends on your definition of "safe" -- a security feature that you will
>> silently not enable on older kernels doesn't sound super safe to me.
>> Unfortunately this is a limitation of open(2) that we cannot change --
>> which is why the openat2(2) proposal I've been posting gives -EINVAL for
>> unknown O_* flags.
>> There is a way to probe for support (though unpleasant), by creating a
>> test O_MAYEXEC fd and then checking if the flag is present in
>> /proc/self/fdinfo/$n.
> Which Florian said they can't do for various reasons.
> It is a major painpoint if there's no easy way for userspace to probe
> for support. Especially if it's security related which usually means
> that you want to know whether this feature works or not.

I used "safe" deliberately (not "secure" which didn't make sense in this
sentence). According to the threat model, if the kernel doesn't support
the feature, it should be ignored by userland. In this case, it fit well
with the current behavior of open(2). I agree that the openat2(2)
behavior handling flags is the good way to do it (whitelisting), but the
O_MAYEXEC flag should not change the userland behavior on its own,
because it depend on a global policy. Even being able to probe for
O_MAYEXEC support does not make sense because it would not be enough to
know the system policy (either this flag is enforced or not…).

Les données à caractère personnel recueillies et traitées dans le cadre de cet échange, le sont à seule fin d’exécution d’une relation professionnelle et s’opèrent dans cette seule finalité et pour la durée nécessaire à cette relation. Si vous souhaitez faire usage de vos droits de consultation, de rectification et de suppression de vos données, veuillez contacter Si vous avez reçu ce message par erreur, nous vous remercions d’en informer l’expéditeur et de détruire le message. The personal data collected and processed during this exchange aims solely at completing a business relationship and is limited to the necessary duration of that relationship. If you wish to use your rights of consultation, rectification and deletion of your data, please contact: If you have received this message in error, we thank you for informing the sender and destroying the message.

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.