activation: Implement From<FileDescriptor> for OwnedFd

[cgwalters]

I think this crate predates I/O safety in std, but now that OwnedFd is part of std we can use it.

I want to have most of my crates use #[forbid(unsafe_code)] and this helps.

Assisted-by: OpenCode (claude-opus-4-6)

[lucab]

Hey Colin 👋
Yes this library predates FD io-safety. Retrofitting needs an MSRV bump beforehand.

There are two broader topics related to the safety of these methods though:

• Internally there are some optional std::env::remove_var() steps. Those were not initially unsafe in Rust, but they are in the latest edition, so eventually we'll need to surface those same unsafe bits in this library.
• Are the FDs that we get through sd-activation really single-owned? I think the answer to this is "no", as you can easily get the same FDs again by calling the same activation-helper function multiple times (without the unset-env flag).

If we tie the two things together, I think the conclusion is that this library has no way of correctly producing a single-owned OwnedFd without introducing an unsafe barrier somewhere (either for env manipulation or for RawFD conversion).
Unfortunately, I fear it will always be up to the consuming application to guarantee the safety invariants for this, as both env and inherited-FDs are process-owned resources (i.e. binary-wide globally mutable state)

[cgwalters]

Internally there are some optional std::env::remove_var() steps. Those were not initially unsafe in Rust, but they are in the latest edition, so eventually we'll need to surface those same unsafe bits in this library.

To be clear I'm trying to avoid unsafe in my higher level crates (calling this one); it would of course be nice to reduce unsafe usage here and in other crates.

If we tie the two things together, I think the conclusion is that this library has no way of correctly producing a single-owned OwnedFd without introducing an unsafe barrier somewhere (either for env manipulation or for RawFD conversion).

Right, this is discussed in rust-lang/rust#116059 - it's not just systemd but also wayland and the venerable jobserver protocol.

[cgwalters]

Digging in see also swick/listen-fds-rs#1 which especially links to rust-lang/libs-team#623 which is about the creation side.