First, I recently came upon this project through listenfd. It looks really nice!
There is however something I wonder about: would it be possible to turn this library into a crate? This way, I could do systemd-like socket-passing between two processes of my own. For the context, I'm trying to make a daemon run with systemd socket-passing, yet still be usable with no-systemd systems.
I believe that systemfd is a great base to do that: if I could just run the daemon as root, it'd do exactly what I want it to. The only issue is, that running the daemon as root is a potential security issue, which means that at some point I must drop privileges. While it'd be possible to do it at the beginning of the daemon only when it's currently running as root, it's some additional code that'll be dynamically dispatched on with all the potential failure cases that entails, rather than code that's just unconditionally executed. Which means, I think it would be best to make systemfd itself drop the privileges after opening the socket. But it's not reasonable to expect systemfd to support all the ways of dropping privileges, nor all use cases (for complete context, I'd be spawning multiple daemons).
Do you think such a refactoring would make sense, to basically do the opposite of listenfd as a crate? :)
Hello,
First, I recently came upon this project through
listenfd. It looks really nice!There is however something I wonder about: would it be possible to turn this library into a crate? This way, I could do systemd-like socket-passing between two processes of my own. For the context, I'm trying to make a daemon run with systemd socket-passing, yet still be usable with no-systemd systems.
I believe that systemfd is a great base to do that: if I could just run the daemon as root, it'd do exactly what I want it to. The only issue is, that running the daemon as root is a potential security issue, which means that at some point I must drop privileges. While it'd be possible to do it at the beginning of the daemon only when it's currently running as root, it's some additional code that'll be dynamically dispatched on with all the potential failure cases that entails, rather than code that's just unconditionally executed. Which means, I think it would be best to make systemfd itself drop the privileges after opening the socket. But it's not reasonable to expect systemfd to support all the ways of dropping privileges, nor all use cases (for complete context, I'd be spawning multiple daemons).
Do you think such a refactoring would make sense, to basically do the opposite of
listenfdas a crate? :)