rtld: allow attaching to JID after loading

[fabian.freyer_physik.tu-berlin.de]

Summary

Allow executing dynamic executables within a jail without them or their libraries being present within the filesystem root of the jail.

Test Plan

jail -c path=/ jid=1234 persist
/libexec/ld-elf.so.1 -j 1234 /bin/ls

[fabian.freyer_physik.tu-berlin.de]

• full context
• initialize jid variable

[fabian.freyer_physik.tu-berlin.de]

• finalized patch

[kevans]

Tagging kib and jamie to start with, perhaps.

[kib]

You do understand that with your patch, parts of the image code is executed un-jailed, and part of it is executed jailed, all sudden for it.

I do not see why cannot you do something similar (or perhaps better) with LD_PRELOAD. ld-elf.so.1 duty is to link the application, not to provide random OS-level services.

[fabian.freyer_physik.tu-berlin.de]

In D19277#412997, @kib wrote:

You do understand that with your patch, parts of the image code is executed un-jailed, and part of it is executed jailed, all sudden for it.

Yes. The point is that linking happens outside the jail, so that the executable and libraries do not have to reside within the jail filesystem.
This allows for e.g. jails with path=/var/empty or read-only filesystems.

I do not see why cannot you do something similar (or perhaps better) with LD_PRELOAD.

How?

ld-elf.so.1 duty is to link the application, not to provide random OS-level services.

For static binaries, this is possible using an open, jail_attach, fexecve wrapper (see e.g. https://gitlab.com/jetpack-containers/jexec-static), however, it's not possible to perform any OS-level setup between link time and execution time.

An alternative approach might be to publish the _rtld symbol and allow passing in the auxiliary vector, env and argv - and then write a wrapper that calls _rtld, then jail_attach, then jump into the entry point of the executable. Would this approach be better?

[kib]

In D19277#413003, @fabian.freyer_physik.tu-berlin.de wrote:

In D19277#412997, @kib wrote:

You do understand that with your patch, parts of the image code is executed un-jailed, and part of it is executed jailed, all sudden for it.

Yes.

No.

The point is that linking happens outside the jail, so that the executable and libraries do not have to reside within the jail filesystem.

Not linking, but some code execution of the application happens outside the jail.
At very least, all constructors are executed there.

This allows for e.g. jails with path=/var/empty or read-only filesystems.

I do not see why cannot you do something similar (or perhaps better) with LD_PRELOAD.

How?

Write dso which calls jail_attach() in its constructor.

ld-elf.so.1 duty is to link the application, not to provide random OS-level services.

[fabian.freyer_physik.tu-berlin.de]

In D19277#413005, @kib wrote:

At very least, all constructors are executed there.

You're right, I'll abandon this revision and try to look at the other approach.

I do not see why cannot you do something similar (or perhaps better) with LD_PRELOAD.

How?

Write dso which calls jail_attach() in its constructor.

Is there a way I can guarantee this gets called as the first constructor?

[fabian.freyer_physik.tu-berlin.de]

@kib, could RTLD_LO_EARLY help here?

[kib]

In D19277#413097, @fabian.freyer_physik.tu-berlin.de wrote:

@kib, could RTLD_LO_EARLY help here?

I do not see how the internal rtld flag can be useful for you.

LD_PRELOAD libraries' constructors are called as soon as possible in the global dependency order. Simply, this means that they are called right after all needed libraries are initialized. So I suspect that you do not need to arrange anything special for LD_PRELOAD to give you the required functionality.