Magst Du das auch mal an #783889 schreiben? Tolle Arbeit, es wäre ärgerlich wenn das verloren geht.
Grüße Marc On Tue, Jul 13, 2021 at 09:17:09PM +0200, Dennis Filder wrote: > From: Dennis Filder <d.fil...@web.de> > Subject: Bug#990855: sudo: enable python plugin support > To: 990...@bugs.debian.org > Reply-To: Dennis Filder <d.fil...@web.de>, 990...@bugs.debian.org > Date: Tue, 13 Jul 2021 21:17:09 +0200 > X-Debian-PR-Package: sudo > List-Id: <sudo.tracker.debian.org> > X-PTS-Package: sudo > X-Spam-Score: (---) -3.3 > X-Spam-Report: torres.zugschlus.de Content analysis details: (-3.3 > points, 5.0 required) pts rule name description ---- > ---------------------- ------------------------------------------- -1.9 > BAYES_00 BODY: Bayes spam probability is 0 to 1% > [score: 0.0000] -2.3 RCVD_IN_DNSWL_MED > RBL: Sender listed at https://www.dnswl.org/, > medium trust > [2a02:16a8:dc41:100:0:0:0:132 listed in] > [list.dnswl.org] 0.0 T_SPF_TEMPERROR > SPF: test of record failed (temperror) 0.0 FREEMAIL_FROM > Sender email is commonly abused enduser mail > provider (d.filder[at]web.de) 0.0 > T_SPF_HELO_TEMPERROR SPF: test of HELO record failed (temperror) 0.2 > HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level > mail domains are different 0.1 DKIM_SIGNED > Message has a DKIM or DK signature, not necessarily > valid 0.5 DKIM_INVALID DKIM or DK > signature exists, but is not valid 0.5 FREEMAIL_FORGED_FROMDOMAIN 2nd > level domains in From and EnvelopeFrom > freemail headers are different -0.5 > MAILING_LIST_MULTI Multiple indicators imply a widely-seen list > manager > > 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. -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
