PAM Authentication Misconfigured

Bug #1070039 reported by Justin Chudgar
This bug affects 3 people
Affects Status Importance Assigned to Milestone
radicale (Ubuntu)

Bug Description

When radicale (v7.1) is set to use PAM, authentication always fails with the following messages:
    2012-10-22T14:01:27.500042-07:00 tiny unix_chkpwd[21918]: check pass; user unknown
    2012-10-22T14:01:27.500108-07:00 tiny unix_chkpwd[21918]: password check failed for user (justin)
    2012-10-22T14:01:27.500920-07:00 tiny python: pam_unix(login:auth): authentication failure; logname=root uid=124 euid=124 tty= ruser= rhost= user=justin
    2012-10-22T14:01:27.502605-07:00 tiny python: pam_sss(login:auth): authentication failure; logname=root uid=124 euid=124 tty= ruser= rhost= user=justin
    2012-10-22T14:01:27.502673-07:00 tiny python: pam_sss(login:auth): received for user justin: 10 (User not known to the underlying authentication module)
    2012-10-22T14:01:27.510433-07:00 tiny ccreds_chkpwd[21919]: error reading cached credentials

    2012-10-22 14:01:27,481 - DEBUG: Sanitized path: /justin/calendar/
    2012-10-22 14:01:27,481 - DEBUG: Request content:
        <?xml version="1.0" encoding="UTF-8"?>
        <D:propfind xmlns:D="DAV:" xmlns:CS="" xmlns:C="urn:ietf:params:xml:ns:caldav"><D:prop><D:resourcetype/><D:owner/><D:current-user-principal/><D:supported-report-set/><C:supported-calendar-component-set/><CS:getctag/></D:prop></D:propfind>
    2012-10-22 14:01:27,482 - INFO: Checking rights for collection owned by justin
    2012-10-22 14:01:27,482 - DEBUG: User justin found
    2012-10-22 14:01:27,483 - DEBUG: The PAM user belongs to the required group (radicale)
    2012-10-22 14:01:31,747 - DEBUG: Wrong PAM password
    2012-10-22 14:01:31,748 - INFO: justin refused
    2012-10-22 14:01:31,748 - DEBUG: Answer status: 401 Unauthorized



    auth [success=4 default=ignore] nullok_secure
    auth [success=3 default=ignore] use_first_pass
    auth [success=2 default=ignore] minimum_uid=1000 action=validate use_first_pass
    auth [default=ignore] minimum_uid=1000 action=update
    auth requisite
    auth required
    auth optional minimum_uid=1000 action=store

    auth optional delay=3000000
    auth [success=ok new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die]
    auth requisite
    session [success=ok ignore=ignore module_unknown=ignore default=bad] close
    session required readenv=1
    session required readenv=1 envfile=/etc/default/locale
    @include common-auth
    auth optional
    session required
    session optional
    session optional
    session optional standard
    @include common-account
    @include common-session
    @include common-password
    session [success=ok ignore=ignore module_unknown=ignore default=bad] open

When using ipython as root, the commands `import pam`; `pam.authenticate('justin','password')` returns True. When using `sudo -u#124 ipython` the same commands return False. This seems to incidate the the user `radicale` was not initially setup properly, though I am mystified about how.

Tags: quantal
no longer affects: pam
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in radicale (Ubuntu):
status: New → Confirmed
Revision history for this message
richud ( wrote :

Hi Justin,
Have you tried the latest 0.8 git? It fixed my CardDAV issue with iPhone and I think there has been a lot of work done on the backend bits like pam.

Revision history for this message
Silvio-frischi (silvio-frischi) wrote :

I got the git version to work but only if i run it as root. When using a dedicated user (radicale) the
python function pam.authenticate(user, password) returns wrong even if the password is correct. I have no idea why this happens.

Revision history for this message
neomilium (neomilium) wrote :


Same here, catch it: dedicated user (radicale) can not authenticate using pam when user's password is stored in /etc/shadow due to permissions...
Authentication of users with password stored in LDAP (for example) do work.
As a workaround, you could try to add radicale to shadow group... but that's a pity.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers