Package: sudo
Version: 1.9.17p2-7
Severity: wishlist

Hi Marc,

in the course of getting sssd back into Debian testing, I came across
this last RC bug to fix:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1129522

The bug report is valid and reproducible in a test setup.

In a previous bug fix, it was decided that libsss-sudo owns the
sudoers: entry in nsswitch.conf. When we install the package, it adds
sudoers: sss and sudo immediately stops seeing /etc/sudoers.

There are two meaningful approaches how to address this: add the
sudoers: entry to base-files (and make it an official field in
nsswitch.conf) or (and I think this hadn't come up, so far) sudo
itself owns that nsswitch.conf key/entry.

In fact, sudo works well with /etc/sudoers without an entry in
nsswitch.conf. However, it does not hurt if `sudoers: files` exists in
nsswitch.conf, either. And what package could better own this entry in
nsswitch.conf than sudo itself???

So here is my idea:

   * you add a debian/sudo.nss file into the sudo src:pkg with the
following content:
     ```
     sudoers database-add

     sudoers first files
     ```

   * And for all other consumers, such as sssd, we add:

     debian/control:
     Pre-Depends: sudo (>= <version-that-adds-the-above-file>)

     debian/lib<foo>-sudo.nss
     ```
     sudoers database-require

     sudoers after=files <foo>
     ```

What do you think? If I have to fix #1129522 only from within
libsss-sudo, it gets really hacky and I'd like to avoid that.

Thanks!
Mike

Hi Mike,

Shouldn't src:sudo's libsss-sudo.deb deliver that file, and to where?

I am planning to do an experimental upload of sudo soonish, so we can
actually try that. I'd like to hear the oder sudo team members' opinion
first, though.

In the long run, Debian should have a package like nss-helper that can
own the nss files and provide programmatic interfaces to them. This
should be discussed on debian-devel.

But of course we need a quickfix for this because of sssd.

Greetings
Marc

Hi Marc,

```
sudoers database-add

sudoers first files
sudoers last sss
```

And it nearly worked:

CASE-1: OK

   * no sudoers: key in nsswitch.conf
     -> result (on install):    sudoers: files sss (correct)
     -> result (after removal): no sudoers: key anymore (correct)

CASE-2: FLAWED

   * `sudoers: files` in nsswitch.conf
     -> result (on install): `sudoers: files` (so unchanged, wrong!)
     -> result (on removal): no sudoers: key anymore (also wrong)

CASE-3: FLAWED

   * `sudoers: files ldap` in nsswitch.conf
     -> result (on install): `sudoers: files ldap` (wrong, should be:
files ldap sss)
     -> result (on removal): `sudoers: ldap` (also wrong, should be:
files ldap)

   * etc.

Great!!!

Indeed. Though, not as high a prio for me as the solving the current
situation.

That'd be great. Thanks!

Mike

Hi Mike,

I wasn't aware of dh_installnss. Ignore the questions in my previous
mails that could be answered by man dh_installnss.

Why is that wrong?

Why is that wrong?

I understand why that is flawed.

And putting that in sudo.nss package does it right?

I just mailed a proposed specification.

Greetings
Marc

Hi Marc,
sss`, not `sudoers: files`.

The point is, that dh_installnss cannot handle adding two nss
providers in one .nss file gracefully.
back to that. But it removes the complete sudoers: key (note, again
with the above .nss config for libsss-sudo).

Yes, I assume it will. (I must admit, it is a theory, but I can test that).

Ack.

Mike

YEZZZ, it does!

What I tested:

   * build sudo from unstable with this patch:

```
diff -Nru sudo-1.9.17p2/debian/changelog sudo-1.9.17p2/debian/changelog
--- sudo-1.9.17p2/debian/changelog	2026-09-08 14:22:41.000000000 +0000
+++ sudo-1.9.17p2/debian/changelog	2026-09-09 20:32:38.000000000 +0000
@@ -1,3 +1,10 @@
+sudo (1.9.17p2-9~sunweaver1) UNRELEASED; urgency=medium
+
+  * debian/sudo.nss:
+    + Authoritatively manage sudoers: entry in nsswitch.conf.
+
+ --  <locadm@libsss-sudo-1129522>  Wed, 09 Sep 2026 20:32:38 +0000
+
  sudo (1.9.17p2-8) unstable; urgency=medium

    * Mention in NEWS that secure_path was shortened (Closes: #1141402)
diff -Nru sudo-1.9.17p2/debian/sudo.nss sudo-1.9.17p2/debian/sudo.nss
--- sudo-1.9.17p2/debian/sudo.nss	1970-01-01 00:00:00.000000000 +0000
+++ sudo-1.9.17p2/debian/sudo.nss	2026-09-09 20:32:38.000000000 +0000
@@ -0,0 +1,3 @@
+sudoers database-add
+
+sudoers first           files
```
   * build sssd with this patch:

```
diff -Nru sssd-2.13.1/debian/changelog sssd-2.13.1/debian/changelog
--- sssd-2.13.1/debian/changelog	2026-09-08 13:05:35.000000000 +0200
+++ sssd-2.13.1/debian/changelog	2026-09-08 22:15:48.000000000 +0200
@@ -1,3 +1,13 @@
+sssd (2.13.1-4~local2) unstable; urgency=medium
+
+  * Team upload.
+
+  * debian/libsss-sudo.nss:
+    + Since 1.9.17p2-9, the sudoers: entry is managed by the sudo package and
+      libsss-sudo can simply piggy-back on that. (Closes: #1129522).
+
+ -- Mike Gabriel <sunweaver@debian.org>  Tue, 08 Sep 2026 22:15:48 +0200
+
  sssd (2.13.1-3) unstable; urgency=medium

    * debian/tests/control: Explicitly have tests requiring
openssh-client depend
diff -Nru sssd-2.13.1/debian/control sssd-2.13.1/debian/control
--- sssd-2.13.1/debian/control	2026-09-08 13:05:33.000000000 +0200
+++ sssd-2.13.1/debian/control	2026-09-08 22:15:48.000000000 +0200
@@ -372,6 +372,7 @@
  Package: libsss-sudo
  Section: libs
  Architecture: any
+Pre-Depends: sudo (>= 1.9.17p2-9~), ${misc:Pre-Depends}
  Depends: ${misc:Depends}, ${shlibs:Depends}
  Description: Communicator library for sudo
   Utility library to allow communication between sudo and SSSD for caching
diff -Nru sssd-2.13.1/debian/libsss-sudo.nss
sssd-2.13.1/debian/libsss-sudo.nss
--- sssd-2.13.1/debian/libsss-sudo.nss	2026-09-08 13:05:33.000000000 +0200
+++ sssd-2.13.1/debian/libsss-sudo.nss	2026-09-08 22:15:48.000000000 +0200
@@ -1,3 +1,3 @@
-sudoers	database-add
+sudoers	database-require

Hi Marc,

Any ETA for an upload that fixes this bug (#1147179)? If the route
described in my bug report is the viable solution, then getting sssd
back into Debian testing depends on fixing this bug.

Mike

Doing this and installing the resulting package causes nsswitch.conf to
grow a line
"sudoers:"
with nothing after the colon. Is that the indended result?

Greetings
Marc

Hi Marc,

Ouch. Indeed. Just tested on a fresh system (Debian testing machine).
Let me check my incus container where I debugged the whole topic. One
sec...

Mike

Hi Marc,

I can confirm your observation when upgrading from 1.9.17p2-8 to my
patched version:

```
diff -Nru sudo-1.9.17p2/debian/changelog sudo-1.9.17p2/debian/changelog
--- sudo-1.9.17p2/debian/changelog      2026-09-08 14:22:41.000000000 +0000
+++ sudo-1.9.17p2/debian/changelog      2026-09-09 20:32:38.000000000 +0000
@@ -1,3 +1,10 @@
+sudo (1.9.17p2-9~sunweaver1) UNRELEASED; urgency=medium
+
+  * debian/sudo.nss:
+    + Authoritatively manage sudoers: entry in nsswitch.conf.
+
+ --  <locadm@libsss-sudo-1129522>  Wed, 09 Sep 2026 20:32:38 +0000
+
  sudo (1.9.17p2-8) unstable; urgency=medium

    * Mention in NEWS that secure_path was shortened (Closes: #1141402)
diff -Nru sudo-1.9.17p2/debian/sudo.nss sudo-1.9.17p2/debian/sudo.nss
--- sudo-1.9.17p2/debian/sudo.nss       1970-01-01 00:00:00.000000000 +0000
+++ sudo-1.9.17p2/debian/sudo.nss       2026-09-09 20:32:38.000000000 +0000
@@ -0,0 +1,3 @@
+sudoers database-add
+
+sudoers first           files
```

When purging sudo and installing anew, the nsswitch.conf looks good.

This probably means there is something wrong with dh-nss. .o( #!$?(%§$%§ )

Taking a closer look.

Mike

Hi Marc,

This needs to be addressed in dh-nss. I have proposed a fix via:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1148069

Thanks for being on that journey with me!
Mike

So we are on hold while this is being sorted out?

Greetings
Marc

Hi Gioele, hi all,

ping via BTS @ dh-nss maintainer, cross-posting to the other related
bugs affected by this, to keep other people in the loop.

People start asking about when sssd is fixed (because autofs is also
impacted by sssd not being in testing).

For the background story and how this all is related:

   * autofs is not in testing, because sssd is not in testing
   * sssd is not in testing because of #1129522
   * to get sssd fixed (#1129522) it needs sudo bug #1147179 getting fixed
   * to get the approach suggested in #1147179 fully functional dh-nss needs
     love (#1148069)
   * this also impact the Debian Edu 14 development, but this is not so
     pressing at the moment, because we are still busy with fine-polishing
     the Debian Edu 13 release

@Gioele (dh-nss maintainer): let me know if there is anything we can
do to speed up the upcoming dh-nss release. Thanks.

Cheers,
Mike

Control: tags 1148069 - patch
simple fix like the one proposed here does not properly cover all the
possible upgrade paths (for arbitrary changes to .nss files). Upgrades
are hard.

I'll try now a different strategy: making the maintscript snippets go
back to a clean state before each upgrade. On paper it works, but I'm
afraid it may cause intermittent issues because there will be a window
of time in which the service will not be enabled in /etc/nsswitch.conf.
In case of a failed upgrade that window may be arbitrarily long and if
that service is something needed to log in, the admin may end up locked
out of their accounts.

Another option, more in line with what sssd and autofs need at the
moment, would be to state something along the lines of ".nss files can
only be added to or removed from a package; changing the content of .nss
files between package versions is not allowed without additional ad-hoc
code in maintscripts".

Both options are unsatisfactory. Option 2 is perhaps the best to unblock
the current sssd situation.

I'll do some other testing and play with these two options during the
weekend, then release a version that will at least unblock sssd.

Ideas and comments are welcome!

Hi Gioele,

Thanks for the info update and for providing a fix to unblock sssd.

Mike

Hi Mike,

On Fri, 02 Oct 2026 15:58:00 +0000 Mike Gabriel <sunweaver@debian.org> wrote:
matches the reality, can you please confirm my reading of the solution
you agreed upon in the other bugs?

 From <https://bugs.debian.org/1147179#30>:

## sudo

sudoers database-add
sudoers first  files

## libsss-sudo

Pre-Depends: sudo (>= $some-version)

sudoers database-require
sudoers after=files  sss

Regards,

Hi Gioele,

Confirming! That's the proposed solution, indeed.

Mike

Hi, I have uploaded dh-nss v1.8~exp2 to experimental. The new code
should fix the issue that affect sssd and sudo (although many other
problems are still lurking.)

Please test. I'll wait for your feedback before uploading v1.8 to unstable.

Regards,