On Tue, Jul 13, 2021 at 05:09:25PM +0200, Marc Haber wrote:
> On Tue, Jul 13, 2021 at 09:10:32AM +0200, Michael Prokop wrote:
> > So maybe it makes sense to provide a sudo-python package, similar to
> > what's available with sudo-ldap already?
>
> I THINK that we were planning to get rid of sudo-ldap anyway
> post-release (see #783889), but I don't remember the state of
> discussion.
It fizzled out. To recap:
* One problem is that sudo puts an entry into /etc/nsswitch.conf that
has no business of being there in the first place since NSS is a
mechanism for order-invariant entity resolving whereas sudo uses its
plugins for combined entity resolution and policy rule evaluation
which is not order-invariant. Also, despite the manpage for
nsswitch.conf wrongly claiming the opposite, as far as I can tell
sudo never uses NSS facilities for its plugins, but instead
implements its own in plugins/sudoers/sudo_nss.{c,h} which doesn't
make sense to me.
* Changes to that entry are not preservable across removals/purges
which violates DPM.
* sudo-ldap should be transformed into a package that only ships the
plugin.
* Sudo's approach to plugins is unlike anything I've seen.
The goal(s) for bookworm should/could be:
* Copy the entry from /etc/nsswitch.conf to
e.g. /etc/sudo/plugins.conf and patch sudo to use that and simply
ignore/warn about the other thereafter. The points below could be
left for trixie, but this one is a must since any error here has the
potential to break libc's NSS for everyone. No longer having to
worry about that will make life much easier.
* Try to split the packages sudo and sudo-ldap into sudo, sudo-common
and sudo-plugin-ldap. sudo-common must ship the update-sudo-plugins
script that regenerates /etc/sudo/plugins.conf from whatever
implements change-preserving configuration of the plugins (note:
plugin order matters, so that has to be preserved, too; sudo also
implements a subset of the nsswitch.conf short-circuting behaviour
which also needs to be covered; some plugins are in mutual conflict,
e.g. the SSSD and LDAP plugins; no idea how to best express/default
that (maybe some preference score)).
Oddities in the architecture of the plugin APIs might make this very
difficult or even impossible.
Also, to load a plugin, it has to be configured explicitly in
/etc/sudo.conf which the user has to do by hand.
/etc/sudo/plugins.conf only configures which facilities will
actually be used and in what order.
* Plugin packages then have to call update-sudo-plugins upon
installation/removal. During their first installation they should
infer their configuration state from what's in
/etc/sudo/plugins.conf already. sudo-common probably needs to
provide another helper script for that.
* A problem is that under sudo-ldap the LDAP plugin was always loaded
because it had the same name as the non-LDAP plugin in the sudo
package. Setups which don't have it explicitly enabled in
/etc/sudo.conf (i.e. essentially all of them) could thus break
during the migration since the LDAP plugin will be named to
sudoers_ldap.so afterwards. IIRC the only way to prevent that is to
patch sudo to first try loading sudoers_ldap.so before sudoers.so if
it is installed and issue a warning about this fallback behaviour
being deprecated.
Additional matters:
* The Python plugin should probably allow referencing the exact Python
version from the beginning, e.g. sudo-plugin-python3.9. But since
it's considered a beta feature this is not urgent.
Regards.
