Dear Maintainer,

After upgrading util-linux to 2.42.1-4 it was impossible to use su.

I got a "Permission denied" message, which makes it impossible to go to the
root shell.

I have found a workaround by creating the following symlinks:

ln -s /usr/lib/pam.d/su /etc/pam.d/su
ln -s /usr/lib/pam.d/su-l /etc/pam.d/su-l

I ran into the same problem here. Looking at the APT log, I see that the upgrade from 2.42.1-3 to 2.42.1-4 deleted a bunch of PAM config files. Could that be the cause?

Martin-Éric

in /usr/lib/pam.d." The later obviously aren't sourced by PAM as they
should be.

Martin-Éric

Some pam modules have been moved from /etc/pam.d to /usr/lib/pam.d.

This also affects e.g. i3lock, which includes login, now living in
/usr/lib/pam.d. The result is, that i3lock cannot be unlocked any more
entering the correct password.

Dear PAM maintainers,
Dear debhelper maintainers,

util-linux 2.42.1-4 switched to debhelper compat v14, which puts the
PAM files into /usr/lib/pam.d.

So it appears PAM is not handling the files in /usr/lib/pam.d
correctly.

Please advise.

Best,
Chris

From what I can tell this is because `su -` uses the PAM config for
`su-l`, which does stuff like `auth include su`. This
include-variant is broken in the current libpam0g.

  cat /usr/lib/pam.d/su-l
  #%PAM-1.0
  auth		include		su
  account		include		su
  password	include		su
  session		optional	pam_keyinit.so force revoke
  session		include		su

Workaround for su users in the meantime: use `su`, not `su -`.

Chris

Please find a patch that works for me attached.

Chris

ma 15.6.2026 klo 12.18 Chris Hofstaedtler (zeha@debian.org) kirjoitti:

No, this clearly is not libpam0g being broken since merely linking the
files to their former location fixed it i.e. libpam0g can find the
configs at the previous location just fine and it restores 'su -'
operation. What this instead looks like is that something in the code
misses /usr/lib/pam.d in its search path.

Martin-Éric

So what you are saying is that libpam0g's code for "include" is
broken, or at least inconsistent with the support for /usr/lib/pam.d.

The posted patch fixes this.

Best,
Chris

I can confirm that both the patch posted by Chris Hofstaedtler in message 47 and the patch in https://salsa.debian.org/vorlon/pam/-/merge_requests/27 fix the issue with swaylock. Greetd continues to be broken, but it no longer prints an error message to journald pointing the finger at PAM so I believe this is unrelated.

control: tags -1 patch
    Chris> So what you are saying is that libpam0g's code for "include"
    Chris> is broken, or at least inconsistent with the support for
    Chris> /usr/lib/pam.d.

I don't think pam in Debian cliams to (or does) support /usr/lib/pam.d.
So, I think that moving files there is broken.

See https://lists.debian.org/tsl34zfqjx5.fsf@suchdamage.org
for my rationale for not supporting /usr/lib/pam.d

I think this bug should be reassigned away from pam.

ma 15.6.2026 klo 21.56 Sam Hartman (hartmans@debian.org) kirjoitti:

AFAIK debhelper-compat 14 enforces installing everything to /usr. If
this is not supported by PAM, to which package this bug gets
reassigned is a whole discussion to itself. Otherwise, it would be a
good idea for PAM to have both /etc/pam.d/ and /usr/lib/pam.d in its
search path.

Martin-Éric

retitle 1140029 I said in 2023 that pam would not support/usr/lib/pam.d: login, su and others should not use it
tags 1140029 wontfix
thanks

I'm definitely open to some sort of mitigation here to be more
aggressive about making it clear that /usr/lib/pam.d is not supported,
and dealing with interim damage.
I continue to believe that for pam style configs without dropins and the
like, /usr/lib/pam.d is not a good solution.
Systemd designed its config to support that model. Pam did not.

Well, dh_installpam in debhelper compat 14 does now install the
files into /usr/lib/pam.d. It's not that util-linux actively chose
to do this.

Without the patch, /usr/lib/pam.d DOES work; except as a source for
include files. So, Debian's PAM does half-support it, courtesy of
upstream.

With the patch, the support would be at least more complete.

From a really quick look at PAM earlier today, it seems PAM supports
libeconf. Per my understanding of things, libeconf is what provides
the support for "systemd-style" configs. Not sure how the
integration looks like.

If you don't want Debian to support /usr/lib/pam.d, then I think you
should at least revert all upstream commits that try to support
/usr/lib/pam.d; get dh_installpam to put the files into /etc/pam.d,
and get these packages fixed:

account-utils: /usr/lib/pam.d/{passwd,pwupd-chfn,pwupd-chsh,pwupd-passwd}
libkscreenlocker6: /usr/lib/pam.d/{kde,kde-fingerprint,kde-smartcard}
polkitd: /usr/lib/pam.d/polkit-1
systemd: /usr/lib/pam.d/systemd-user
util-linux: /usr/lib/pam.d/{login,remote,runuser,runuser-l,su,su-l}

A lintian error would also be in order.

Chris

And given the centrality of PAM, please also seek consensus in d-devel@
about going against upstream instead of just fixing the Debian patch,
for example by merging
<https://salsa.debian.org/vorlon/pam/-/merge_requests/27>.

Regards,

    Chris> On Mon, Jun 15, 2026 at 12:57:03PM -0600, Sam Hartman wrote:
    Chris> Well, dh_installpam in debhelper compat 14 does now install
    Chris> the files into /usr/lib/pam.d.
    u
That sounds like a critical bug in debhelper then.
I was not consulted on that change.
It seems like talking to the PAM maintainer about where to install pam
    Chris> config files might have been a clever thing to do.

I am trying to deal  with this on the side while dealing with a busy
work day, and I'm not going to file a RC bug against debhelper without a
better understanding.
My take is that it's surprising to me that pam reads anything out of
/usr/lib/pam.d at all, and I made my position that I thought moving pam
configs there  was a bad idea back in 2023.

I appreciate that  we have an operational mess, and I'm open to
suggestions that actually get us  to a state where things are working
for our users quickly, and also make it clear that /usr/lib/pam.d should
not b eused.

Hi!

But this behavior was "accepted" when the packaging for util-linux
got bumped to compat level 14. So while I think the problem is with
debhelper, part of the point for the compat levels is so that
maintainers can change behavior and check whether that breaks those
packages at their convenience.

Given the kind of regression this has caused, I think this should be
reverted in util-linux now, either with a global compat downgrade or
perhaps a targeted one for just the dh_installpam invocation (via
DH_COMPAT for example).

Even if there's some partial support, this is still a severe regression.

I don't think it's fair to put pressure on Sam / the pam maintainer,
for something that had been clearly stated previously was not supported.

IMO, util-linux should revert the specific breaking change, and this
report should be reassigned to debhelper.

Thanks,
Guillem

Am Mon, Jun 15, 2026 at 11:28:30PM +0200 schrieb Gioele Barabucci:

/me somewhat silently waves to vorlon,
you are being missed, Steve.

u-l -5 removed the usage of `include`, so `su -l` works again.
However it seems we were "lucky" that u-l exposed this problem.
Imagine other packages would have switched first, then we'd now have
a lot more packages installing files into /usr/lib/pam.d.

I fail to see how resisting against PAM upstream is easier for us
all than fixing the Debian patch that breaks the upstream feature,
using a patch that multiple people tried out.

Best,
Chris

For the record, here is trixie's version:
https://manpages.debian.org/trixie/libpam-runtime/pam.7.en.html#FILES

| FILES
|
| /etc/pam.conf
| the configuration file
|
| /etc/pam.d
| the Linux-PAM configuration directory. Generally, if this directory is
| present, the /etc/pam.conf file is ignored.
|
| /usr/lib/pam.d
| the Linux-PAM vendor configuration directory. Files in /etc/pam.d override
| files with the same name in this directory.

I hope this documentation is not wrong, and Debian's Linux-PAM supports this as
documented.

Best,
Chris

to 18.6.2026 klo 11.18 Chris Hofstaedtler (zeha@debian.org) kirjoitti:

It indeed states so.

If this somehow still needs to be patched for reality to match the man
page, I would think that other distributions that migrated everything
to /usr a few years before Debian would have a patch that we can use
for this.

Martin-Éric

Chris Hofstaedtler wrote:

That seems to work, yes. What broke was the silent removal of
modified /etc/pam.d/ files after the recent update.

I had overrides e.g. in su (where I had uncommented the su without
password directive), which got lost silently. At least a su.dpkg-old
file was left in /etc/pam.d. Maybe that’s the desired behaviour, but it
took me a while to understand the issue.

Once again for the record, this text in pam(7) been added upstream in
version 1.2.0 (2015) and shipped in Debian since Debian 10 buster (2019,
now old-old-old-stable).

Regards,

    Chris> On Tue, Jun 16, 2026 at 12:44:05AM +0200, Guillem Jover wrote:
    >> IMO, util-linux should revert the specific breaking change,

    Chris> u-l -5 removed the usage of `include`, so `su -l` works
    Chris> again.  However it seems we were "lucky" that u-l exposed
    Chris> this problem.  Imagine other packages would have switched
    Chris> first, then we'd now have a lot more packages installing
    Chris> files into /usr/lib/pam.d.

Yes!
I really appreciate your help on this, and I deeply regret that I missed
the text in the man page.

Current state:

* dh_installpam is installing to /etc/pam.d
* PAM has been fixed to support /usr/lib/pam.d including include support
* There is an RC bug open on pam to figure out any next steps.

I have a patch that logs an error on the use of /usr/lib/pam.d. That's
kind of a big hammer, and I want to reread my 2023 reasoning and double
check that's the right answer for Debian before releasing that patch.  I
plan to pull out the documentation from pam.7 and close the RC bug at
that point.  By the beginning of July, I plan to move forward on a more
permanent direction--one of:

* Add the log call on use of /usr/lib/pam.d (with a way for downstreams
  to turn it off at build time)
  * Have a clear set of questions for debian-devel
  * Restore the text in pam.7 and update the mini-policy to allow for
  installing in /usr/lib/pam.d

Hi, all

I discovered another issue exposed in this incident. Since trixie, login is
migrated to the util-linux package and becomes no longer essential. As a result,
it is not assured that /etc/pam.d/login must exists. However, There are some
packages that still install pam configurations which include login instead of
common-auth. I found weston and greetd that are such examples using code
search.

I wonder if we should add a lintian rule that can detect this.

Cheers,

Miao Wang

Yes, I also noticed this and filed bugs for them where there were
none. login's Priority: required hides this problem somewhat.

Most of the bugs are fixed, still open TTBOMK:

* weston #1140097 - done in exp
* greetd #1140127 not sure where the replies went, but I got a reply
from the maintainer they're looking into it

Sounds reasonable to avoid introducing new cases where upstreqm
ships a RedHat-style PAM config.

Chris

Can I ask (and this probably should be moved to a separate discussion in
new bug report): why?

Are the energy and time going into this effort well spent?

Upstream has a certain functionality, users appreciate that
functionality, downstream distros and sysadmins mwould like to make use
of that functionality. What does Debian users gain by removing it?

Please note that most of the base packages in a modern Debian system
already use the "configuration in /etc overrides /usr/" paradigm. How is
PAM in Debian so different from all other services that it requires
abandoning that paradigm?

Regards,