Dear Maintainer,


   * What led up to the situation?

was seeking to run radicale with PAM authentication. I installed the python3-pam
package, and the service, was able to recognize it, however the interface it was
expecting was all wrong.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

I updated radicale/auth/pam.py to reflect the interface that is in python3-pam
 version 0.4.2-19.

   * What was the outcome of this action?

The service now supports PAM authentication, I am able to login/logout and it
stops me when I put in bad creedentials.

   * What outcome did you expect instead?

This is the expected outcome.

Quoting Robert Ismo (2025-11-01 23:32:18)
[...]
[...]

Looks like this bugreport is tied to bug#562702. Tagging accordingly.

Thanks for the patch - I will apply that now.

 - Jonas

Quoting Jonas Smedegaard (2025-11-06 19:09:39)

Looking closer, I have decided to not apply your patch after all:

Debian package python3-pam seems badly maintained upstream, but more
importantly calling PAM requires granting the web server access to
shadow group, which is a security risk.

You are of course free to take that risk, but I won't maintain a patch
for doing that.

What I recommend is to use the more convoluted approach of running a
dedicated authentication proxy as documented in the Debian package.

Since you have invested the time in making the patch, you might prefer
the more lightweight approach over my recommended safer one.  If so,
then I encourage you to propose upstream to include not one but two
PAM plugins, with the second one having your patches applied.  If
upstream chooses to adopt your patch, then I will not get in the way of
distributing it as well - I just won't invest time in maintaining it
specifically for Debian when I find it unsafe and not strictly needed.

Kind regards, and sorry for not accepting your work,

I will keep this bugreport open, for others running into the same issue
who might prefer your lightweight fix over my convoluted and safer one.

 - Jonas

Quoting Jonas Smedegaard (2025-11-06 19:45:10)

Your patch is now included with the radicale source package, but
commented out. That way it should be slightly easier for someone
prefering lightweight over secure to rebuild the package.

Thanks again,

 - Jonas

Hello, thank you for the feedback.
It seems the radicale package has the pam implementation for a newer
version of the python3-pam package, are you suggesting getting a
python3-pam-x.y.z package into upstream? I would be down. do you have
any guidance on how I would do this? I am on the debian-mentors mailing
list, would I reach out there for this?

Quoting Robert Ismo (2025-11-06 21:14:23)

 1. suggest upstream to add a fork of their PAM plugin with your patch
    applied
 2. package for Debian the python PAM module needed for the upstream
    PAM plugin.

Yes, for the 2nd option it makes sense to reach out to the
debian-mentors team, indeed.

Enjoy, whichever path you choose :-)

  - Jonas

I'm all for dropping features for whatever reason. I suggest three things:

1) Remove the option from /etc/radicale/config, so people don't think they can enable it.
2) Comment in the readme that PAM won't work for the reasons you provided. This will stop people from relying on the upstream documentation or other tutorials online (which say it should just work).3) Change the error message to journald when radicale is started with PAM enabled, which currently reads "An exception occurred during server startup: PAM authentication requires the Python pam module", implying that PAM authentication will work with the right packages. This is what I thought until I found this bug report. It should probably say "PAM authentication is not supported" instead.
The benefit to you is that fewer people like me will bother you trying to understand why it's not working (if they don't stumble upon this bug first). I'm not sure whether an undocumented feature worse than a documented unfeature.

Hi Borden,

Quoting Borden (2026-03-14 01:49:28)

As I wrote in my 1st reply, I will not get in the way of people wanting
to setup a lighter but also less secure system, so I will not remove
options. It seems I am therefore not convinced that 1) is a good idea,
but please do try be even more specific, if you think that some
concrete edits would be sensible without hiding options for more
adventurous users.

Same for 2): Can you suggest concrete changes to the documentation?
That would help me reflect on whether I find that an improvement over
the existing texts, and something that I feel that I am ok maintaining.

Thanks,

 - Jonas

13 Mar 2026, 21:17 by jonas@jones.dk:
If users want to patch radicale to authenticate over plain text or black magic, they can. Upstream has instructions on how to install through pip and git. It seems easier and safer to maintain patches against source than against Debian's updates.

Directing determined users to upstream seems far less aggravating to fielding complaints and bug reports. At least for me it is.

Debian package python3-pam is incompatible with radicale. This is
considered an upstream issue of low importance: directly accessing PAM
is discouraged, safer methods exist, including a tested, packaged and
documented method via apache2 authnz-external module.

Quoting Borden (2026-03-14 03:08:08)

Debian radicale package does not imply that it works with PAM.

The contained code include functionality that is assumed fully
functional yet requires libraries not in Debian. That functionality is
not advertised as working in Debian, nor is upstream documentation
mangled to silence mentions of its existence: Dedicated Debian users
may choose to include an unofficial Python package with the needed
library, in which case that functionality becomes functional for them.

Since directly accessing PAM is not considered of high priority, the
added maintenance burden of including a package (either to adjust code
or to strip PAM-related documentation and/or code) is *not* acceptable.

Users wanting to not use Debian-packaged radicale but instead use pip
are welcome to do so, but such bypassing of Debian packages is
irrelevant to track as an issue for this package.

Yes, patches against source is indeed better, and I encourage
contributing patches against upstream source to gain support for the
PAM module provided in Debian.
determined users to upstream - upstream needs to be nudged to accept
the patch (or something functionally similar that covers multiple PAM
implementations) for this bugreport to be considered resolved, and
until then the Debian package documentation references this bugreport
when talking about (still generally discouraged) direct PAM acces.

In short: Please engage upstream to have them enable support for the
PAM module in Debian, e.g. using the patch attached to this bugreport.


 - Jonas

No dispute. Judging from the activity on this bug, I'm probably the only person whom this will ever affect, so you can probaly close under "user educated."
All I can say is that it wasn't obvious to me that it _wouldn't_ work until I did some research.  Maybe the package readme file was the place to start, but "Do not use on Debian" was not in my top search results. I try to make a good faith effort to exhaust my options before contacting a human, so that helped me find this bug reports.
Someone else can take up that cross, especially considering how my bug reports get received. I saw the configuration option and thought "Wonder if I can do it?" I don't really remember how or when I figured out that I wasn't supposed to use it. That means I also can't remember what would have to change to learn this earlier in my troubleshooting process.

I hope something here was useful.

Quoting Borden (2026-09-20 09:26:41)

I can imagine others than you and me running into this issue.

Yes, I can imagine not only me and you but everyone else reading this
bugreport coming to the conclusion that they choose not to take on the
task of pushing the contained patch upstream - i.e. effectively this
bugreport being stalled. But even then I don't see that as a failure:
It still exists as a place of detailed documentation about the issue.

In fact, I wrote the above summary as the first sentence of my previous
post *exactly* because I think this bugreport might be helpful in the
future: Afterwards I tagged that post as the current "summary" of this
bugreport, which causes the bugreport web page to include that first
paragraph in the structured top section.

Currently the the package descriptions for radicale and radicale-uwsgi
mentions "PAM", the README.Debian for radicale documents the
recommended way to enable PAM authentication, and README.Debian for
python3-radicale mentions explicitly the discouraged way to enable PAM,
referncing this bugreport.

I certainly appreciate the conversation we've had here, regardless of
my not choosing to take on the work or doing the changes that you had
envisioned.  I sure hope you are not discouraged from bringing up other
issues you come across in the future - here or elsewhere.

 - Jonas