[Pkg-sssd-devel] Bug#783889: sudo-ldap, libsss-sudo: need to coordinate modifications to /etc/nsswitch.conf

[Dennis Filder]

To summarize from discussions on sudo at 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.