Allow mixing libc and raw backend on Linux (at least for linux_execfn)

[oech3]

At uutils/coreutils, AT_EXECFN is used at multi-call binary to match with AppArmor's policy (avoid argv[0] hijack) and raw backend is used to avoid LD_PRELOAD injection. However, LD_PRELOAD is required by some GnuTests.

It can be avoided if rustix::raw::param::linux_execfn() is possible.

[gurchetansingh]

I have a question: why isn't adding the required functionality to libc feasible in the case? Is there a rule against things like execfn?

I personally want to make the libc backend to more linux-raw-sys agnostic.

#1589

[oech3]

libc backend already supports linux_execfn. But it can be hijacked by LD_PRELOAD. So we cannot use it.

[sunfishcode]

Are you asking to be able to use the linux_raw backend's linux_execfn, while using the libc backend for other functions?

Could you explain the problem with LD_PRELOAD hijacking? It would seem that if someone is in a position to set LD_PRELOAD for a binary, they can do a lot of things other than just hijack getauxval.

[oech3]

someone is in a position to set LD_PRELOAD for a binary, they can do a lot of things

Yes. But I can still reduce attack vector (maybe, except for stdbuf) and raw is still useful for performance.
(I'm considering to use raw by default, but use libc for few parts)

[sunfishcode]

Adding a way to mix linux_raw and libc in the same configuration would require a fair amount of new configuration complexity. I might consider it if there were an important use case. However, at this point, I don't yet see how mitigating against LD_PRELOAD hijacking of just getauxval is important.