On Monday, 2 November 2026 10:37:28 Central European Standard Time Florian
Weimer via devel wrote:
> > 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.
>
>
> The connection is that the language implementations in Fedora
> (specifically their run-time components) may make assumptions about the
> trustworthiness of the execution environment.
>
> Typical examples of things that could be problematic for SUID binaries:
> obtaining log file paths from the process environment, automatically
> loading code based on environment variables or files in the user's home
> directory, honoring umask when creating files, automatically writing
> crash dumps (whether in the current directory or elsewhere), providing a
> special syntax for command line arguments that are processed by the
> runtime instead of the application.
>
> If the language runtime does this, it may create impossible-to-fix
> vulnerabilities if the binaries are made SUID. (Of course, this is
> where usermode comes in.)
The std run-time before main reads no environment variables. It does not load
code from the environment or from $HOME. It reads RUST_BACKTRACE when a panic
happens. That only controls whether a backtrace goes to stderr. RUST_MIN_STACK
sets the stack size of threads spawned later. Neither changes which files are
opened or which code is loaded.
A panic prints a message to stderr. Core dumps are the kernel's job, and
setuid processes are non-dumpable by default.
userhelper doesn't use env_logger or anything else that reads RUST_LOG.
Logging goes to the journal or syslog.
Umask: std never changes or consults it. File creation uses whatever umask the
process inherited.
There is no run-time argument syntax like the JVM's -X flags or
JAVA_TOOL_OPTIONS. argv goes to the application unchanged.
Before main, std makes sure fds 0 to 2 are open. It reopens any closed one on
/dev/null.
It sets SIGPIPE to ignored, and an ignored signal survives exec. Our fork/exec
code in common might therefore pass an ignored SIGPIPE to the privileged
child. std::process::Command resets it, but our code doesn't use Command. I
haven't confirmed whether we reset it ourselves, so I'll check and fix it if
not.
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
