On Friday, 30 October 2026 14:53:20 Central European Standard Time Richard W.M. Jones via devel wrote: > On Fri, Oct 30, 2026 at 01:51:01PM +0000, Richard W.M. Jones via devel > wrote: > > On Thu, Oct 29, 2026 at 12:54:54PM +0100, Fabio Valentini wrote: > > > > > On Wed, Oct 28, 2026 at 6:47 PM Florian Weimer via devel > > > <[email protected]> wrote: > > > > > > > > > > > > > > > * Aoife Moloney via devel-announce: > > > > > > > > > > > > > > > > > The privilege-separated design is preserved and sharpened: the only > > > > > setuid-root binary is `userhelper`, kept to PAM calls, privilege > > > > > transitions, and `exec`. > > > > > > > > > > > > > > > > It his binary written in Rust? > > > > > > > > > > > > > > > > The upstream Rust security team has not documented that Rust is safe > > > > to > > > > use in SUID binaries, and the standard library (and therefore most > > > > crates) do not take this special operating environment into > > > > consideration. > > > > > > > > > Can you elaborate what you mean here? I don't really see a connection > > > between programming language and SUID use. And I don't see how the > > > Rust standard library plays any role here either - it contains zero > > > functionality related to unix user / group support. > > > > > > It's things like, does the runtime detect when it is being run as SUID > > and clean out / refuse to use environment variables (such as > > LD_PRELOAD). A lot of this comes from the C library, so if Rust is > > using glibc then that's a good start, but I guess the language itself > > (or more likely, Rust-specific libraries) might require attention too. > > > > As Florian hinted, a great deal of this is unwritten knowledge and/or > > learnings from decades of security incidents. > > > And don't take this to mean that I'm opposed to the proposal. > If you really have to do SUID, using a memory safe language is > a good idea.
It's not that I didn't look at the old usermode C code. I wrote C for Samba the last 15+ years. We do a lot of impersonation. From my commit message for privilege.rs setresuid/setresgid clear the saved IDs too, closing a privilege re-escalation path the original C implementation left open. A partial failure partway through a transition (e.g. setresgid succeeding but setresuid failing) would otherwise leave the process holding a changed gid without a matching uid. The caller would have no safe way to continue or roll back. Such a failure now aborts the process immediately instead of returning an error. become_root returns a token that become_user consumes by value, so the one-way root-to-user transition is enforced at compile time rather than by convention. See https://www.cs.cmu.edu/~aldrich/papers/classic/tse12-typestate.pdf However review of the code is welcome. Best regards Andreas -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
