Differences between revisions 1 and 2
Revision 1 as of 2021-11-25 20:20:43
Size: 4111
Editor: ZugSchlus
Comment:
Revision 2 as of 2021-11-25 20:31:39
Size: 4111
Editor: ZugSchlus
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
The sudo team is planning to work on the split package between sudo and sudo-ldap. This page is our discussion method to plan. The information given here is based on work by Dennis Filter, thank you very much for that. The sudo team is planning to work on the split package between sudo and sudo-ldap. This page is our discussion method to plan. The information given here is based on work by Dennis Filder, thank you very much for that.

sudo LDAP roadmap

motivation

The sudo team is planning to work on the split package between sudo and sudo-ldap. This page is our discussion method to plan. The information given here is based on work by Dennis Filder, thank you very much for that.

what we currently have

  • Two packages sudo and sudo-ldap, conflicting with each other, both offering a fully-fledged sudo.
  • sudo has over the years grown a plugin system that can dynamically load shared objects.
  • the LDAP code is not yet a fully flexible plugins, it replaces the sudoers.so object from the plain sudo with an LDAPized version
  • sudo-ldap needs a change in /etc/nsswitch.conf while not using the nss library itself.
  • That entry in /etc/nsswitch.conf 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's apprach to plugins is unique and has a lot of uncommon concepts.

what we are planning to do

(this is work in progress and subject to change without notice)

  • 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
    • 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
      • 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.
    • 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.
      • We have above stated update-sudo-plugins that generates /etc/sudo/plugins.conf. What is actually the case?
    • insert explanation of those oddities here
  • sudo-ldap should be transformed into a package that only ships the plugin.
    • 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.
    • A possible solution for 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.
    • We should talk to Upstream before doing such a patch
  • Move the entry from /etc/nsswitch.conf to e.g. /etc/sudo/plugins.conf
    • This needs a sudo patch
    • sudo should still honor the /etc/nsswitch.conf entry to preserve backwards compatibility AND compatibility to upstream's documentatoin.
    • This compatibility should probably be kept indefinetely unless we can convince upstream to replicate the move
    • This also needs talking to upstream
    • 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.
  • 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.
      • What does it mean to infer configuration state?
    • sudo-common probably needs to provide another helper script for that.