I have a program that is both an executable and a shared library. I
compile it with -fpic and -pie on x86/64. When run, it sets LD_PRELOAD to
itself, then runs another program (such that LD_PRELOAD kicks in - sort of
a "call back"). When originally developed, this all worked fine. And it
still works on the development system.

However, on the target system (which is running a later version of Ubuntu),
it used to work, but now does not.

When I run it on the target system, I get the following error message:

ERROR: ld.so: object '/path/to/my/Program' from LD_PRELOAD
cannot be preloaded (cannot dynamically load position-independent
executable): ignored.

The program then runs - but of course, doesn't work as intended.

My sense is that this is some sort of "security" thing, as Ubuntu is known
for removing functionality in the name of "security". Can anyone confirm
or deny this and/or explain why this was done?

Anyway, one workaround would be to compile the program as two separate
programs - one the executable and the other the library, but I am curious
if any other workarounds are available.

--
"Every time Mitt opens his mouth, a swing state gets its wings."

(Should be on a bumper sticker)

On Fri, 26 Jan 2024 13:39:45 -0000 (UTC), Kenny McCormack wrote:

> I have a program that is both an executable and a shared library. I
> compile it with -fpic and -pie on x86/64. When run, it sets LD_PRELOAD to
> itself, then runs another program (such that LD_PRELOAD kicks in - sort of
> a "call back"). When originally developed, this all worked fine. And it
> still works on the development system.

Seems this kind of thing never worked right, and was explicitly
disabled a while back
<https://patchwork.ozlabs.org/project/glibc/patch/20190312130235.8E82C89CE49C@oldenburg2.str.redhat.com/>
(found from
<https://stackoverflow.com/questions/59074126/loading-executable-or-executing-a-library>).

On 2024-01-26, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Fri, 26 Jan 2024 13:39:45 -0000 (UTC), Kenny McCormack wrote:
>
>> I have a program that is both an executable and a shared library. I
>> compile it with -fpic and -pie on x86/64. When run, it sets LD_PRELOAD to
>> itself, then runs another program (such that LD_PRELOAD kicks in - sort of
>> a "call back"). When originally developed, this all worked fine. And it
>> still works on the development system.
>
> Seems this kind of thing never worked right, and was explicitly
> disabled a while back
><https://patchwork.ozlabs.org/project/glibc/patch/20190312130235.8E82C89CE49C@oldenburg2.str.redhat.com/>
> (found from
><https://stackoverflow.com/questions/59074126/loading-executable-or-executing-a-library>).

Yes, this kind of thing works right. Glibc is executable; you can
run your /lib/ld.so.6 or whatever it is called to get an informational
message about the library.

I suspect this will work even on that system where your trick isn't
working.

It is likely that Kenny has to prepare this object in some special
way. It has to be primarily be a shared library that also happens
to support execution.

It's probably not enough to compile the code relocatable, but otherwise
build a normal executable (even though that happened to work before).

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

In article <up190l$313qt$9@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Fri, 26 Jan 2024 13:39:45 -0000 (UTC), Kenny McCormack wrote:
>
>> I have a program that is both an executable and a shared library. I
>> compile it with -fpic and -pie on x86/64. When run, it sets LD_PRELOAD to
>> itself, then runs another program (such that LD_PRELOAD kicks in - sort of
>> a "call back"). When originally developed, this all worked fine. And it
>> still works on the development system.
>
>Seems this kind of thing never worked right, and was explicitly
>disabled a while back
><https://patchwork.ozlabs.org/project/glibc/patch/20190312130235.8E82C89CE49C@oldenburg2.str.redhat.com/>
>(found from
><https://stackoverflow.com/questions/59074126/loading-executable-or-executing-a-library>).

OK, so it *is* tied to version of glibc. Thanks.

That explains why it works on the older system, but fails on a newer one.

And not really a Ubuntu thing - more of a "Red Hat" thing.

P.S. Good read on stackoverflow. Good to see at least some people
refusing to drink the Kool Aid.

Anyway, it does sound like it boils down to needing to compile the program
twice - once as shared lib and once as executable. Not as convenient as
before, but so it goes. It makes you wish that there was some way to
"bundle" the two outputs together into a single file - sort of like how
other, more complex filesystems (e.g., the old MacOS) worked.

But so it goes...

files - one compiled
--
Just remember:

Pence is all the evil, with none of the crazy.

On 2024-01-27, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> OK, so it *is* tied to version of glibc. Thanks.

The "ld.so" dynamic loader is something that comes from glibc, that's why.

> That explains why it works on the older system, but fails on a newer one.
>
> And not really a Ubuntu thing - more of a "Red Hat" thing.

If that patch is upstreamed into glibc, it's a thing in every
glibc system.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

In article <20240127090419.728@kylheku.com>,
Kaz Kylheku <433-929-6894@kylheku.com> wrote:
>On 2024-01-27, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> OK, so it *is* tied to version of glibc. Thanks.
>
>The "ld.so" dynamic loader is something that comes from glibc, that's why.
>
>> That explains why it works on the older system, but fails on a newer one.
>>
>> And not really a Ubuntu thing - more of a "Red Hat" thing.
>
>If that patch is upstreamed into glibc, it's a thing in every
>glibc system.

Yup. Well said.

--
There's nothing more American than demanding to carry an AR-15 to
"protect yourself" but refusing to wear a mask to protect everyone else.

On Sat, 27 Jan 2024 11:44:27 -0000 (UTC), Kenny McCormack wrote:

> Good to see at least some people refusing to drink the Kool Aid.

Looking forward to your alternative, Kool-Aid-free glibc fork.

On Fri, 26 Jan 2024 13:39:45 -0000 (UTC), Kenny McCormack wrote:

> I have a program that is both an executable and a shared library.
> ... When run, it sets LD_PRELOAD to itself, then runs another program
> (such that LD_PRELOAD kicks in - sort of "call back").

Seems to me you’re doing it in an unnecessarily complicated way. Surely
the entire executable is not needed to be in the callback; so why not
separate out the part that does not need to be in the shared library, into
the executable proper, and have it import the shared library, just like
the code you are calling?