move to using rustix instead of custom syscall wrappers

[cgwalters]

Have you seen https://crates.io/crates/openat ? I use it in rpm-ostree, curious whether you considered using it instead of rolling custom wrappers here.

[cyphar]

I hadn't seen it, I'll take a look. It might let me get rid of some of the more awful parts of the syscall wrapping code I have.

[cyphar]

From a quick look, I'm not entirely convinced switching makes a lot of sense.

My main concern is that there are certain "bad signs" with what flags get passed by default (it's okay for most programs but not for us). It appears to me that there isn't a way to explicitly set flags like O_NOCTTY or O_NOFOLLOW. I also worry a bit about the file creation methods (we have to be very careful considering how trailing symlinks are treated). Not to mention quite a few *at flags are missing (like mknodat) so we'd need to wrap those anyway.

(This is just from a few minutes of looking, I'll take a closer look sometime later when I get a chance.)

[cgwalters]

All good comments, though I had more hoped the response would be "Let's patch/fix the openat crate".

A motivation I have here is I maintain https://crates.io/crates/openat-ext and I have plans to significantly extend it with methods from https://gitlab.gnome.org/GNOME/libglnx/blob/8f34033b256da5a8e2cc66faf8e81cfdfb9cdf37/glnx-fdio.c - things like "atomically replace a file's contents using O_TMPFILE, falling back if that's not available" etc.

If there isn't a shared base wrapper for openat in the Rust ecosystem, then anyone who wants to operate on those will have to convert between crate-specific wrappers.

Or I guess, the other approach would be for this crate to take over the role of openat.

[cyphar]

All good comments, though I had more hoped the response would be "Let's patch/fix the openat crate".

Don't get me wrong, I would be happy to work on patching the openat crate to handle these usecases -- it's just that I'm not sure if that matches the author's long-term goals for openat (I am usually quite anxious about proposing large changes to projects I've never worked with before -- I get the feeling that most maintainers don't appreciate it).

Another thing I'm still trying to come to terms with is how much abstraction there is in Rust programs (for a systems programming language at least). I'm not sure how I feel (especially coming from C) about not being sure what the exact syscall arguments being used are. But maybe that's just me still being quite green to Rust overall.

I will point out that in pathrs I try to use Files for internal "O_PATH fd" storage -- and I found a few Rust stdlib bugs related to it (and fixed them). So I'm definitely not against fixing issues in other projects to avoid creating incompatible structs or traits.

If there isn't a shared base wrapper for openat in the Rust ecosystem, then anyone who wants to operate on those will have to convert between crate-specific wrappers.

I'm definitely in favour of there being a gold-standard crate for *at wrappers in Rust.

Or I guess, the other approach would be for this crate to take over the role of openat.

Probably not the best choice, pathrs has a more specific purpose (though I would hope most projects would use pathrs rather than openat for the usecase of "open a path inside this directory" -- due to all of the security issues with naive openat usage).

[cyphar]

All good comments, though I had more hoped the response would be "Let's patch/fix the openat crate".

I've posted tailhook/openat#25 and we can see what the maintainer thinks.

[sunfishcode]

I just came across this issue; in case it's useful, posish is a crate that provides safe low-level wrappers for all the at functions, including openat2 on Linux. It supports the portable (but much more abstract) Dir in cap-std, which implements openat2+RESOLVE_BENEATH+RESOLVE_NOMAGICLINKS-style sandboxing (using actual openat2 when available, and a variety of techniques otherwise).

[cgwalters]

Hmm. Another one? I guess I'd hoped for more centralization here...nowadays e.g. nix also has openat. But, your code certainly looks good.

[sunfishcode]

Yeah; one of the biggest challenges in this space is finding the right abstraction levels 😅 .

[cyphar]

It seems most likely we're going to end up moving everything to rustix because it has a reasonable interface for readdir (which we need and would be too ugly to write a small wrapper around).