⇤ ← Revision 1 as of 2021-11-25 20:20:43
4111
Comment:
|
4111
|
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
- 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.
- 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.
- During their first installation they should infer their configuration state from what's in /etc/sudo/plugins.conf already.