On Fri, Sep 06, 2019 at 07:20:51PM +0200, Christian Brauner wrote: > On Sat, Sep 07, 2019 at 03:07:39AM +1000, Aleksa Sarai wrote: > > On 2019-09-06, Mickaël Salaün <mickael.salaun@xxxxxxxxxxx> 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. What about just trying to violate the policy via fexecve() instead of looking around in /proc? Still ugly, though. Tycho
