pambase 20190105.1-1 breaks email

GeneArch · 2019-01-05 18:20:55

pambase 20190105.1-1 caused failure for email.[1]
The error I saw immediately was from postfix failing to authenticate users via saslauthd which in turn blames pam. Downgrading back to 20171006-1 restores email funtioning.

The problem stems from change to:
/etc/pam.d/other

which replaced
password required pam_unix.so
with
password required pam_deny.so

Does this mean that things like dovecot and postfix need to have explicit additional files in /etc/pam.d so that email authentication work without relying on the catch all "other" file? This was the only change I could find for the pambase package.

Logs say:

saslauthd[22214]: pam_warn(smtp:auth): function=[pam_sm_authenticate] flags=0x8000 service=[smtp] terminal=[<unknown>] user=[lists] ruser=[<unknown>] rhost=[<unknown>]
saslauthd[22214]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure
saslauthd[22214]: do_auth         : auth failure: [user=lists] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error] 
postfix[] :               warning: SASL authentication failure: Password verification failed

[1] I also email arch general with same info as I was unable to find email address to reach the packager (Dave Reisner)

Last edited by GeneArch (2019-01-05 20:59:55)

Trilby · 2019-01-05 20:20:06

The need to properly configure pam is already covered (and has been for some time) in the wiki:
https://wiki.archlinux.org/index.php/Do … entication

Also, please edit your post to add code tags around commands and output (which would avoid the proble you had with square brackets).

GeneArch · 2019-01-05 20:33:13

Thanks for comments and link to dovecot pam info - have added that to pam.d

Now what about postfix - I found no similar pam info on the wiki for postfix - do you know what would be needed for that? Same as for dovecot only in a file named what - smtp, smtpd, postfix?
Also if this might break running systems it might help if there was a warning on this update. It certainly came as a surprise to me and others may be similarly caught unawares.

Trilby · 2019-01-05 20:42:41

I can't reply for postfix as that doesn't make sense: postfix doesn't depend on pam (it's nowhere it it's dependency tree). But your issue isn't with postfix, but with saslauthd and/or cyrus-sasl - so look into the documentation for that to ensure you have configured it properly. I've never used it so I can't say how/where that is configured, but there are wiki and man pages on it, I just rely on dovecot.

As for a warning about the "other" file, you really never should have been relying on it in the first place:

pam wiki page wrote:

Like the example of sshd, any pam-aware application is required to install its policy to /etc/pam.d in order to integrate and rely on the PAM stack appropriately. If an application fails to do it, the /etc/pam.d/other policy is applied per default. A permissive policy for it is installed per default (FS#48650).

Also see the linked issue with the new change you are referring to fixed.

Last edited by Trilby (2019-01-05 20:48:00)

GeneArch · 2019-01-05 20:43:08

The fix for postfix is to create /etc/pam.d/smtp containing (not sure we need more than the first 2 lines?) but adding this and updating pambase works (with the dovecot pam file as well as per trilby's post).

auth required pam_unix.so
account required pam_unix.so
password required pam_unix.so
session required pam_unix.so

Trilby · 2019-01-05 20:47:07

Or see:
https://wiki.archlinux.org/index.php/Po … sl_package

GeneArch · 2019-01-05 20:57:45

That sounds right - its saslauthd which is calling on pam. I've yet to find exactly documented somewhere exactly what is needed but the above /etc/pam.d/smtp by trial and error seems to work.

The next trial was to remove the bottom 2 lines and that works fine.

The final result is that /etc/pam.d/smtp

#%PAM-1.0
auth required pam_unix.so
account required pam_unix.so

RalphCorderoy · 2019-02-11 13:03:07

Package at lacks a /etc/pam.d file. https://bugs.archlinux.org/task/61700 tracks the breakage.
It seems like quite a few packages may not be providing a /etc/pam.d file.
Was any survey done on introducing the pambase change to try and spot the omissions in advance?
Does the 'any pam-aware application is required to install its policy to /etc/pam.d in'
mean all packages that depend on pam should have a /etc/pam.d/* in their package contents?
I don't have many packages installed, but this shows at, cifs-utils, kbd, ... are lacking.

pactree -ld1 -r pam | sed 1d | xargs -rtn1 pkgfile -l |& egrep $'\t''/etc/pam\.d/.|^pkgfile'

WorMzy · 2019-02-11 14:48:14

Please do not hijack threads, Ralph.

https://wiki.archlinux.org/index.php/Co … _hijacking

As Gene's issue seems to be resolved and pambase-20190105.1 is now in [core], I am going to take this opportunity to close this thread.

jasonwryan · 2019-02-24 20:27:04

Bug report here: https://bugs.archlinux.org/task/61852 and here: https://bugs.archlinux.org/task/61712

Moving to Apps & DEs.

Arch Linux

#1 2019-01-05 18:20:55

pambase 20190105.1-1 breaks email

#2 2019-01-05 20:20:06

Re: pambase 20190105.1-1 breaks email

#3 2019-01-05 20:33:13

Re: pambase 20190105.1-1 breaks email

#4 2019-01-05 20:42:41

Re: pambase 20190105.1-1 breaks email

#5 2019-01-05 20:43:08

Re: pambase 20190105.1-1 breaks email

#6 2019-01-05 20:47:07

Re: pambase 20190105.1-1 breaks email

#7 2019-01-05 20:57:45

Re: pambase 20190105.1-1 breaks email

#8 2019-02-11 13:03:07

Re: pambase 20190105.1-1 breaks email

#9 2019-02-11 14:48:14

Re: pambase 20190105.1-1 breaks email

#10 2019-02-24 20:27:04

Re: pambase 20190105.1-1 breaks email

Board footer