Re: [PATCH 0/2] fs: support $ORIGIN in ELF interpreter paths

[Christian Brauner]

On 2026-06-28 14:36:52+02:00, Christian Brauner wrote:
> > I think the proposed patch will only change behavior if the
> > interpreter path starts with "$ORIGIN"? That wouldn't work on existing
> > kernels unless you have a directory literally named "$ORIGIN" in the
> > cwd, because "$ORIGIN/..." would be interpreted as a normal relative
> > path.
> 
> I was thinking:

A few other things came to my mind:

(1) memfds: /memfd:woot-woot

    A memfd doesn't have a path so any $ORIGIN type behavior - script or not -
    will be at least useless if not very confusing outside of a sandbox.

    Btw, used by runC to guard against binary overwrite attacks.

(1.1) deleted memfds: /memfd:woot-woot (deleted)

      Same as (1).

(2) deleted executables:

    /woot/woot-woot (deleted)

(3) unrecoverable executable paths

    No path can be resolved at all. What to do?

All of that needs consistent, easy to reason about treatment. Reading through
the glibc implementation of $ORIGIN for shared libraries in rpath - even with
an eye on cutting through most of the complexity - doesn't give me very warm
feelings. It feels very hackish and full of edge cases...

Imho, tying the lookup of the interpreter to the binary itself and making the
kernel responsible for figuring out the relationship by resolving bprm->file
and splicing it with PT_INTERP is terrible.

So, I kinda like the concept of having relocatable dynamic executables but then
let's cut through all the userspace red tape and figure out something that's
super simple and outsources the problem to userspace.

I think the wrap-buddy approach here: https://github.com/Mic92/wrap-buddy is
going in the right direction in that it gets the kernel completely out of the
way. I like that a lot more than moving more nasty bits into the kernel itself.

In a way we have been doing something in systemd that goes in a similar
direction. As of systemd 261 systemd _only_ links against libc and nothing
else.

Any other shared library is dlopen()ened as needed (discoverable via
elf-notes). Lennart wrote about this just a few days ago:
https://mastodon.social/@pid_eins/116781776665322560

This effectively minimizes the work the loader has to do at startup. Imho, your
effort with wrap-buddy is related. To me moving the loader invocation out of
the kernel and into userspace makes a lot of sense to me.