To summarize from discussions on sudo@packages.d.o and elsewhere
(e.g. #990855):
* Sudo has IMO no business of putting an entry into /etc/nsswitch.conf
since NSS is a mechanism for order-invariant entity resolution
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} the
purpose of which doesn't really make sense to me.
* Changes to that entry are not preservable across removals/purges
which violates DPM (as stated).
* Sudo's approach to plugins is unlike anything I've seen. The APIs
move very fast, and there exist several plugin types which make it
somewhat difficult to reason about how to best distribute that
gracefully across several packages. For example, sudoers_ldap.so
does not just include LDAP-related functions, but also duplicates
everything from sudoers.so. This architecture stems probably from
the days before the plugin API was introduced and you had to build
several versions of sudo with different features linked in. Also,
the function pointers are exported in structs which makes rather
hard to tell what each plugin is for which is not helped by the fact
that the type of the plugin is only encoded as an int in the struct.
The goal(s) for bookworm 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.
The sssd maintainers will have to cooperate on this.
* To keep plugins from interfering with each other's config
files/entries, 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 actually 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. (This point somewhat calls into
question the sensibility of trying to preserve changes for
/etc/sudo/plugins.conf: If the user after installing/removing a
plugin has to touch /etc/sudo.conf unconditionally anyway, why can't
we expect him to also touch /etc/sudo/plugins.conf?)
* 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 load it explicitly in /etc/sudo.conf
(i.e. essentially all of them) could thus break during the migration
since the LDAP plugin will be named sudoers_ldap.so afterwards.
IIRC the only non-interactive 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.
