Gate rustix linux_raw backend behind a feature

Gate rustix's linux_raw backend behind a feature and don't enable it by default. It bypasses libc, breaking LD_PRELOAD users such as fakeroot (see #13399 (comment)).

This is a GNU compatibility issue: if GNU coreutils' libc calls can be interposed via LD_PRELOAD, replacing them with direct syscalls changes observable behavior. For a drop-in replacement, uutils should preserve that behavior where practical.

The linux_raw backend should remain available as an opt-in feature, while the default build should use the libc backend for compatibility.

I don't agree. Other utils should not depend on such dirty hack and patched to avoid LD_PRELOAD.

Correct approach is contributing to other utils to use ptrace which also covers static binaries.

@BAMF0

LD_PRELOAD function interposition is a documented and well-established feature, so users are likely to expect it to work. Bypassing libc by default can therefore be a compatibility regression for existing LD_PRELOAD users such as fakeroot.

Perhaps this feature could be a default feature, with an option to disable it with --no-default-features for consumers who want the compatibility of LD_PRELOAD, e.g. Ubuntu.

cc: @BAMF0

Our chmod, id does not viorate about their role. If other utils want to spoof them, then should spoof by proper way.

LD_PRELOAD function interposition is a documented feature of the dynamic linking environment. The ld.so(8) documentation describes LD_PRELOAD as follows:

This feature can be used to selectively override functions in other shared objects.

Documented does not mean any program should support it.

This is a GNU compatibility issue: if GNU coreutils' libc calls can be interposed via LD_PRELOAD, replacing them with direct syscalls changes observable behavior. For a drop-in replacement, uutils should preserve that behavior where practical.

@xtqqczze

Personally, I think this question is a bit complex. Arguably we could state that the GNU coreutils supporting LD_PRELOAD function interposition is a side-effect, rather than an explicit contract.

However, we are entering into the territory of Hyrum's Law here. Simply put: even though it's not a stated feature of the GNU coreutils, it is treated as an observable behavior and something users have come to expect to be there. As @xtqqczze argues, the README.md declares:

Differences with GNU are treated as bugs

and this is a difference, whether promised or not. If this is an acceptable difference, then could we not assume that this warrants a review of the uutils project goals?

About side-effect, GNU previously broke themself's test suite when glibc changed backend syscalls: coreutils/coreutils#161 .

Also when Rust started removing C-dependency about libc call from their eco-system in the future, everything would be broken.

So I don't thnk supporting LD_PRELOAD is a good approach.

Also when Rust started removing C-dependency about libc call from their eco-system in the future, everything would be broken.

I think this is a valid concern, although I'm not necessarily convinced that this is the problem we should be focusing on. Essentially, this does not apply if we are using APIs with explicit libc bindings, like using the libc backend for rustix.

Our discussion, as I see it, should rather be as to whether uutils coreutils could consider using libc for its syscalls by default - where one of the consequences of this decision is compatibility with LD_PRELOAD based tools.

I'm wondering if libc-wrapper rewrite of coreutils still have same worth with Rust rewrite of coreutils.

I guess the same issue exists for date with faketime.

i will fix these tools, soon i will open an issue in these tools

@xtqqczze

@xtqqczze no it is not a gnu compability issue, close that as not planned, these tools are false sense of security and these are 1990s hacks, i do'nt like them

please these tools to avoid these and also please use modern tools, there was better, instead of fakeroot use https://github.com/abligh/fakeroot-ng

please

compability for things that not extremly old, things that extremly old, example there was besides that, some weird hardwares not supported by rustc LLVM dropped them, we do'nt care about these

It is still worth to try fixing fake* itself and link PRs to them at here.

Perhaps, we should start uutils/fake{root,date} supporting static binaries...

We probally don't consider bug-compatibility e.g. usa after free, sagfault. etc.. as GNU compatibility.
We should consider about how should we support kernel or other utility itself's bug too. (fake* has a bug when static binary is target in some sense.) But I really don't think fixing our utils instead of buggy consumers is a good idea...

Perhaps this feature could be a default feature, with an option to disable it with --no-default-features for consumers who want the compatibility of LD_PRELOAD, e.g. Ubuntu.

Turns out Cargo already supports this:

cargo check --features=feat_os_unix,rustix/use-libc --target=x86_64-unknown-linux-gnu

For proper support, we could expose this as a feature of our own:

[features]
use-libc = ["rustix?/use-libc"]

I'm still not a fan of this, but can we import rustix twice with different names with different features to support injection for few syscalls?

Our discussion, as I see it, should rather be as to whether uutils coreutils could consider using libc for its syscalls by default - where one of the consequences of this decision is compatibility with LD_PRELOAD based tools.

I do still think this is worth considering. The target is x86_64-unknown-linux-gnu, after all, not x86_64-unknown-linux-none. On GNU/Linux, libc is part of the platform, and things like LD_PRELOAD interposition are behaviour that existing software might reasonably expect to rely on.

This is bug-compatibility. Consumer expcted crazy things. So it would not work. Solution is clear: fix fake* itself. Linux provides proper interfaces for a long time.

I don't think "fix fake* itself" follows. fakeroot is not a Linux-only hack; it supports multiple Unix-like platforms and deliberately relies on libc interposition.

If GNU coreutils makes an interposable libc call and uutils replaces it with a raw syscall, that's a compatibility difference in uutils. Whether fakeroot could work around it is a separate question.

Also when Rust started removing C-dependency about libc call from their eco-system in the future, everything would be broken.

By the way, it's worth noting that direct syscalls are not universally viable. For example, on Android, native code is expected to interact with the system through Bionic libc, so rustix only supports the libc backend.

Navigation Menu

Repository navigation

Gate rustix linux_raw backend behind a feature #14946

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Gate rustix linux_raw backend behind a feature #14946

Description

Activity

oech3 commented on Sep 29, 2026

xtqqczze commented on Sep 29, 2026

oech3 commented on Sep 29, 2026

xtqqczze commented on Sep 29, 2026

oech3 commented on Sep 29, 2026

xtqqczze commented on Sep 29, 2026

BAMF0 commented on Sep 29, 2026

oech3 commented on Sep 29, 2026

BAMF0 commented on Sep 29, 2026

oech3 commented on Sep 29, 2026

xtqqczze commented on Sep 30, 2026

HackingRepo commented on Sep 30, 2026

HackingRepo commented on Sep 30, 2026

oech3 commented on Sep 30, 2026

oech3 commented on Oct 5, 2026

oech3 commented on Oct 5, 2026

xtqqczze commented on Oct 6, 2026

oech3 commented on Oct 6, 2026

xtqqczze commented on Oct 6, 2026

oech3 commented on Oct 7, 2026

xtqqczze commented on Oct 7, 2026

xtqqczze commented on Oct 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions