* Package name    : radicale-auth-pam
  Version         : 0.2
  Upstream Author : Joseph Nahmias <joe@nahmias.net>
* URL             : https://gitlab.com/jello/radicale_auth_PAM
* License         : GPL3
  Programming Lang: Python
  Description     : PAM authentication plugin for Radicale

Quoting Joseph Nahmias (2019-01-27 03:48:50)

Are you aware that Radicale can already use PAM,
by use of uWSGI and the Apache2 mod-authnz-external module?

The Debian package suggests this approach,
and provides snippets for setting up PAM that way.

I notice that you are upstream author of this plugin,
so I guess you are biased towards using your own implementation.
May I suggest that at least you mention in long description
how access to sensitive material is handled?

For inspiration, libapache2-mod-authnz-external contains this:

Mentioning in long description how security is addressed will help users
decide which approach to take.


 - Jonas

Hello Jonas,

Well, I must confess that I did not thoroughly read that documentation
since it mostly revolved around configuring Apache.  I'm not using WSGI
or a reverse proxy, so I didn't try to solve the problem of
authenticating with PAM in that manner.

Not really, I primarily just wrote it to scratch my own itch when I
couldn't find a PAM auth plugin and decided to share it with the world.
  Also, it was my first foray into Python, so I used it as a learning
experience secondarily.

So this is interesting feedback.  In my docs, I mention that if PAM is
using standard Unix passwd/shadow then the radicale user will need to be
added to the shadow group.

My understanding is that pwauth is setuid in order to access
/etc/shadow; but the process separation would be a security benefit if
pwauth is sufficiently small / auditable.

Obviously, if not using passwd/shadow then this concern doesn't apply.

Perhaps I will write a radicale-auth-PAM-pwauth plugin that calls pwauth
to get the security benefit without needing apache.

I appreciate the comments and review!

Quoting Joe Nahmias (2019-01-28 01:42:32)

Fair enough, I guess.

Avoiding the server-side hassle of using a reverse proxy would instead
require either a) the client-side hassle of getting it to accept a
non-standard port number, or b) running the whole daemon as root with
the security implications that involve.

Either of those options might be valid for some scenarios - e.g.
single-user setup in a controlled environment.

Well, good luck with it!

That sounds like a valuable improvement.  Thanks for considering!


 - Jonas