[Bug dynamic-link/11767] RFE: dlopen of in-memory ET_DYN or ET_EXEC object

[stsp at users dot sourceforge.net]

https://sourceware.org/bugzilla/show_bug.cgi?id=11767

--- Comment #52 from Stas Sergeev <stsp at users dot sourceforge.net> ---
(In reply to Vinícius dos Santos Oliveira from comment #51)
> <https://blog.emilua.org/2025/01/12/software-sandboxing-basics/>.
> 
> fdlopen is mentioned in my article.

What a big article!
I am very interested in sandboxing
under linux, so if there is some
place to discuss things with you
(provided your freebsd knowledge),
that would be excellent. Of course
I need to finish reading your article
first, which takes some time. :)

What I currently use for sandboxing,
is a non-root suid/sgid+landlock,
but that's nothing but a huge mess.
So I am very interested to know
what other OSes offer right now,
and what people think should be added.

> FreeBSD added fdlopen 14 years ago for a concrete use case: allow tests
> (e.g. file permissions) to be done on the file before committing to load it
> in a relatively race-free manner:
> https://freebsd-arch.freebsd.narkive.com/phl97wbJ/fdlopen-3
> 
> That's not a ideological reason. That's a concrete use-case. That's not
> supported on Linux/glibc.

The only *real* reason I am aware
of, against fdlopen, is that you
can't refer to opened solibs via
DT_NEEDED. So even if you fdlopen,
the deps are still loaded by names!
And also that lib itself can't be
a dep of another, as once again you
can't refer to an fd in DT_NEEDED.
So IMHO the first step should be
to enrich ELF format somehow.
But yes, you will never get a
prompt reply in the known dev
communities. All I got, was a huge
amount of trolling and abuse, and
nothing else.


> Patches to add fdlopen on musl were sent 3 years ago yet nothing came out of
> that: https://www.openwall.com/lists/musl/2023/05/08/4
> 
> Musl developers accuse fdlopen as something you only want for "ideological
> reasons":
> https://inbox.vuxu.org/musl/20240801025445.GQ10433@brightrain.aerifal.cx/
> 
> It seems to me that trying to talk to Linux userspace API developers is a
> losing battle and not worth the effort at all.

You can see the quality of
arguments of musl devs right
in this thread, starting from
comment #35 and onward. Judge
it for yourself, as I have no
words when someone ignorant even
of a simple mremap() functionality,
tries to discuss things like this
(and no wonder the very same guy
was the major source of trolling
in an ML, when I tried to discuss
that topic there).
But still, the DT_NEEDED problem
(which of course they never mentioned)
must be solved first.


> On the other hand, every time I interacted with the FreeBSD community to
> include APIs that would fix the gaps for my use cases... I had a
> collaboration that was much more fruitful. I wish for the day when Linux
> userspace API developers learn from FreeBSD folks. It just gets everyone
> stuck doing only what was possible in the 80s and nothing more.

I need to sort out your article
and find if it suggests something
for my use-case. Maybe you are
right that the one should switch
to BSD. :) But at the same time
I haven't seen the concrete and
definite proposal in that area,
that have no problems in itself.

-- 
You are receiving this mail because:
You are on the CC list for the bug.