Support config paths under /usr/

[JustSoup312]

Describe the feature you'd like see implemented in sudo-rs

sudoers configs should be able to be read from /usr/lib/sudo/sudoers and /usr/lib/sudo/sudoers.d/

What problem can be solved with this feature?

In postmarketOS, we use sudo-rs as our default sudo implementation. This has worked fine so far, but we are attempting to limit configs installed to /etc/, reserving it as a sysadmin configuration directory per the concept of hermetic-usr. This is in conflict with sudo-rs, which only supports loading configs from /etc/.

Describe alternatives you've considered

Because sudo-rs only supports loading sudoers from /etc/, the only way we can handle sudoers is to use tmpfiles.d to copy the file from /usr/share/factory/etc/ on first-boot. It would be much easier if sudo-rs was able to read sudoers from a path under /usr/, removing the need for complex config file logic.

Additional context

• Tracking upstream projects that do not support hermetic-usr for configuration uapi-group/specifications#76 (specifically the section at the top on sudo)
• https://uapi-group.org/specifications/specs/configuration_files_specification/ (bit of an explanation on hermetic-usr)

[squell]

We could add this as a compile-time option, which should suffice for this use case.

The prefix-path sudo-rs looks for is already controlled by the "LOCALBASE" environment variable on FreeBSD (to allow it to read from /usr/local/etc/ for instance); we could also enable that on Linux. That would allow using /usr/etc for instance (isn't that a more logical place than /usr/lib/sudo, in keeping with Linux traditions?)

Note: as I understand hermetic-usr, the intent is that everything under /usr is immutable and under control of the OS vendor. In general I would consider /etc/sudoers to be part of the "sysadmin configuration". We make design choices (such as enabling use_pty and pwfeedback by default) around sudo-rs with that in mind. Maybe the use cases of pmOS are limited enough that this is not important, of course.

[JustSoup312]

The prefix-path sudo-rs looks for is already controlled by the "LOCALBASE" environment variable on FreeBSD (to allow it to read from /usr/local/etc/ for instance); we could also enable that on Linux.

That would be a reasonable solution, but the variable name would be sort-of confusing at this point. A compile-time option determining the path might make more sense at that point.

That would allow using /usr/etc for instance (isn't that a more logical place than /usr/lib/sudo, in keeping with Linux traditions?)

/usr/etc/ is only used on OpenSUSE (and libeconf, which was OpenSUSE software first, which is why that's the default there). The paths most commonly used are /usr/lib/<softwarename>/ for systemd and /usr/share/<softwarename>/ for everything else.

as I understand hermetic-usr, the intent is that everything under /usr is immutable and under control of the OS vendor. In general I would consider /etc/sudoers to be part of the "sysadmin configuration". We make design choices (such as enabling use_pty and pwfeedback by default) around sudo-rs with that in mind. Maybe the use cases of pmOS are limited enough that this is not important, of course.

So, hermetic-usr is supposed to be handled by having a main system config in /usr/ provided by a "vendor" (usually whatever OS / distro is being used), optional sysadmin configs in /etc/, and optional user configs in XDG_CONFIG_DIR. So, with sudo-rs, it would make sense for the vendor to configure it with default options and then allow the sysadmin to override with their separate own config file. I don't think abiding by XDG_CONFIG_DIR makes sense for sudo-rs, because that would allow unprivileged users to modify the sudo config. The concepts of overrides may be too complex for something like this at first, which is why I just asked for the option to have configs under /usr/ instead.

[squell]

The prefix-path sudo-rs looks for is already controlled by the "LOCALBASE" environment variable on FreeBSD (to allow it to read from /usr/local/etc/ for instance); we could also enable that on Linux.

That would be a reasonable solution, but the variable name would be sort-of confusing at this point. A compile-time option determining the path might make more sense at that point.

Note that LOCALBASE is a compile time option. With rust/Cargo, it seems the usual route to pass parametric information; e.g. LOCALBASE=/opt cargo build.

Of course the downside is that it will then try to read /opt/etc/sudoers, so perhaps a more flexible thing (on LInux) would be to use something like SUDO_RS_CONFIGDIR=/usr/lib/sudo (which would then have a default path of "/etc")

Of course loading sudoers.d is never done automatically by sudo/sudo-rs, that always happens thru the inclusion of an explicit @includedir directive. But if we make the path configurable at compile-time, I think you would be good to go, right.

[squell]

A similar mechanism already exists to override the version sudo-rs reports itself as (SUDO_RS_VERSION); this helps identify custom builds (such as the one Ubuntu is shipping).

[JustSoup312]

Of course the downside is that it will then try to read /opt/etc/sudoers, so perhaps a more flexible thing (on LInux) would be to use something like SUDO_RS_CONFIGDIR=/usr/lib/sudo (which would then have a default path of "/etc")

Ah, yes, the /etc append would be an issue, so having the config directory be a compile-time option that is just the bare path like you recommended would make things work fine.