[arch-general] pambase update now requires explicit service files in /etc/pam.d/ - dovecot affected
All, With the latest change to pambase, e.g. https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/pambase&id=3552aba772e8bebbe754a4d01f2729e291dd2070 if you have services that rely on pam authentication, such as dovecot, etc.., you will find that your applications an no longer authenticate using pam until you install a specific pam service in /etc/pam.d for that application, e.g. https://wiki.archlinux.org/index.php/Dovecot#PAM_Authentication I recall seeing something about this change coming earlier, but this was the first update where something stopped working as a result. So add whatever additional files you require to /etc/pam.d/ Thankfully the journal messages are good in pointing out the problem. -- David C. Rankin, J.D.,P.E.
On 09/02/19 12:50 am, David C. Rankin wrote:
All,
With the latest change to pambase, e.g.
if you have services that rely on pam authentication, such as dovecot, etc.., you will find that your applications an no longer authenticate using pam until you install a specific pam service in /etc/pam.d for that application,
Although this change is probably not going to affect me but may be this should have been done in two releases. First release where pam_unix.so lines are kept as it is but with new pam_warn.so lines too. This will start throwing warning in log but services will continue to work. Hence alerting the administrator instead of breaking service all-of-sudden. And then in some future release switch pam_unix.so to pam_deny.so. I would also suggest to have a message displayed by pacman after upgrade. Regards, Amish.
Hi Amish,
David C. Rankin wrote:
if you have services that rely on pam authentication, such as dovecot, etc.., you will find that your applications an no longer authenticate using pam until you install a specific pam service in /etc/pam.d for that application,
Although this change is probably not going to affect me but may be this should have been done in two releases.
It affected me and caused data loss. atd(8) couldn't run its jobs, bailed out with the job renamed to start `=', and then cleaned those up when it was re-started. No output from them was gathered. The jobs are often one-offs, hand-written as input to at(1), perhaps weeks or months ago. What they intended to do has been lost. https://bugs.archlinux.org/task/61700 is the bug on package at needing an /etc/pam.d entry. https://bbs.archlinux.org/viewtopic.php?pid=1831377 is a recent thread on this pambase change causing problems. Apparently, I hijacked it so it's now closed. But I'm pleased I did because others that arrive there from Google, like I did, will now have the trail I laid to follow. I also ask there if a check should be in place on all packages that depend on pam to see if they provide /etc/pam.d/foo. If there's not too many exceptions then it may mop up the outstanding ones, and spot future new violations. pactree -ld1 -r pam | sed 1d | xargs -rtn1 pkgfile -l |& egrep $'\t''/etc/pam\.d/.|^pkgfile' -- Cheers, Ralph.
On Mon, 11 Feb 2019 at 16:32, Ralph Corderoy <ralph@inputplus.co.uk> wrote:
https://bbs.archlinux.org/viewtopic.php?pid=1831377 is a recent thread on this pambase change causing problems. Apparently, I hijacked it so it's now closed. But I'm pleased I did because others that arrive there from Google, like I did, will now have the trail I laid to follow.
Please lose that mentality. Just because $searchengine returns a thread that contains one or more of the keywords you entered in the search box, does not mean that you automatically get a free pass to dump your own issue into the thread. Engage your brain, read the topic, evaluate whether your issue is the same and whether you can contribute anything to help with the resolution of the original poster's issue. If what you are going to post will not assist the original poster resolve their issue, then you are hijacking the topic and should return to your search results (or create your own topic, if you have run out of results...) In this case you had no interest in helping the OP, you just wanted a platform to share your own grievances relating to the recent pambase change, and draw attention to an issue with particular importance to yourself. To then try to pass this off as philanthropy is obscene. Don't be surprised if, the next time you pull this sort of stunt, you find yourself banned from the bbs. Regards WorMzy
I don't understand the need for that reaction... On Mon, Feb 11, 2019 at 06:47:23PM +0000, WorMzy Tykashi via arch-general wrote:
On Mon, 11 Feb 2019 at 16:32, Ralph Corderoy <ralph@inputplus.co.uk> wrote:
https://bbs.archlinux.org/viewtopic.php?pid=1831377 is a recent thread on this pambase change causing problems. Apparently, I hijacked it so it's now closed. But I'm pleased I did because others that arrive there from Google, like I did, will now have the trail I laid to follow.
Please lose that mentality. Just because $searchengine returns a thread that contains one or more of the keywords you entered in the search box, does not mean that you automatically get a free pass to dump your own issue into the thread.
Engage your brain, read the topic, evaluate whether your issue is the same and whether you can contribute anything to help with the resolution of the original poster's issue. If what you are going to post will not assist the original poster resolve their issue, then you are hijacking the topic and should return to your search results (or create your own topic, if you have run out of results...)
In this case you had no interest in helping the OP, you just wanted a platform to share your own grievances relating to the recent pambase change, and draw attention to an issue with particular importance to yourself. To then try to pass this off as philanthropy is obscene.
Don't be surprised if, the next time you pull this sort of stunt, you find yourself banned from the bbs.
Regards
WorMzy
On Mon, 2019-02-11 at 18:42 -0800, frederik@ofb.net wrote:
On Mon, Feb 11, 2019 at 06:47:23PM +0000, WorMzy Tykashi via arch-general wrote:
To then try to pass this off as philanthropy is obscene.
Don't be surprised if, the next time you pull this sort of stunt, you find yourself banned from the bbs. I don't understand the need for that reaction...
Since this and similar insinuations and excessive reactions are characteristic for the Linux nerd communities, my guess is that it may be an Echo Chamber Effect, sometimes it even might be psychopathologic. The need for this kind of excessive reactions seems to be compulsion and/or group behaviour. To defame and to utter a threat is the common way of behaving. IOW there is nothing to understand, it's only something to ignore.
On Mon, 11 Feb 2019 18:42:01 -0800 frederik@ofb.net wrote:
I don't understand the need for that reaction...
He posted that he's glad he broke the rules, implying that he'd gladly do it again in the future. A strong reaction is not only warranted, but necessary. Scimmia
On Mon, Feb 11, 2019 at 11:54:22PM -0600, Doug Newgard via arch-general wrote:
On Mon, 11 Feb 2019 18:42:01 -0800 frederik@ofb.net wrote:
I don't understand the need for that reaction...
He posted that he's glad he broke the rules, implying that he'd gladly do it again in the future. A strong reaction is not only warranted, but necessary.
I am sorry to ask this so late in the discussion, but why Arch default of the "other" module was insecure (and hence why the change)? Is there something wrong with pam_unix? Thanks, -- Leonid Isaev
On Tue, 12 Feb 2019, at 12:02, Leonid Isaev via arch-general wrote:
I am sorry to ask this so late in the discussion, but why Arch default of the "other" module was insecure (and hence why the change)? Is there something wrong with pam_unix?
Not inherently. They implemented a suggestion from the upstream product manual and decided that it was OK to break random [authentication related] packages instead of fixing the reverse deps from official repos first and then changing pambase. Either package maintenance responsibilities are really as fragmented as not to care at all or they just ignored it. Given that falconindy is the maintainer of pambase, I'll go with the latter interpretation (no judgement implied).
On Tue, Feb 12, 2019 at 09:15:39AM -0500, Jens John wrote:
On Tue, 12 Feb 2019, at 12:02, Leonid Isaev via arch-general wrote:
I am sorry to ask this so late in the discussion, but why Arch default of the "other" module was insecure (and hence why the change)? Is there something wrong with pam_unix?
Not inherently. They implemented a suggestion from the upstream product manual and decided that it was OK to break random [authentication related] packages instead of fixing the reverse deps from official repos first and then changing pambase.
Either package maintenance responsibilities are really as fragmented as not to care at all or they just ignored it. Given that falconindy is the maintainer of pambase, I'll go with the latter interpretation (no judgement implied).
There is no problem with using upstream defaults (so I personally support the change to the pambase package), and I think that ppl should just fix their stuff to properly work with PAM. But I still don't understand why using pam_unix.so was called permissive policy... Thanks, -- Leonid Isaev
Hi WorMzy,
https://bbs.archlinux.org/viewtopic.php?pid=1831377 is a recent thread on this pambase change causing problems. Apparently, I hijacked it so it's now closed. But I'm pleased I did because others that arrive there from Google, like I did, will now have the trail I laid to follow.
Please lose that mentality.
It's not a mentality, but my subjective opinion borne from experience, and one backed up by an email thanking me from someone that Google later led there.
Just because $searchengine
Not any search engine, the search engine.
returns a thread that contains one or more of the keywords you entered in the search box, does not mean that you automatically get a free pass to dump your own issue into the thread.
It was a thread on exactly the same topic: pambase's recent ditching of a fallback configuration, presumably knowing it would impact packages and their users. If I turned up there, others would, and did.
In this case you had no interest in helping the OP, you just wanted a platform to share your own grievances relating to the recent pambase change,
I aired no grievance. Read it again. I asked questions to try and get an idea of the impact of the pambase change and to ask if I was interpreting an above poster correctly, giving a pipeline to show how I was grokking it.
and draw attention to an issue with particular importance to yourself. To then try to pass this off as philanthropy is obscene.
I think you're just upset because of the implicit criticism of your decision to close the thread, or you need to better understand the meaning of `obscene'.
Don't be surprised if, the next time you pull this sort of stunt, you find yourself banned from the bbs.
It wasn't a stunt. You seem lacking in some essential qualities of a moderator, like moderation. -- Cheers, Ralph.
On 2/8/19 2:20 PM, David C. Rankin wrote:
All,
With the latest change to pambase, e.g.
if you have services that rely on pam authentication, such as dovecot, etc.., you will find that your applications an no longer authenticate using pam until you install a specific pam service in /etc/pam.d for that application, e.g.
https://wiki.archlinux.org/index.php/Dovecot#PAM_Authentication
I recall seeing something about this change coming earlier, but this was the first update where something stopped working as a result. So add whatever additional files you require to /etc/pam.d/
Thankfully the journal messages are good in pointing out the problem.
I wish someone had submitted a bug about this in the first place as this should never have been relegated to thirdparty configuration performed only after reading the wiki. I did not realize there was no bug report for this... well, now there is one: https://bugs.archlinux.org/task/61852 -- Eli Schwartz Bug Wrangler and Trusted User
participants (10)
-
Amish
-
David C. Rankin
-
Doug Newgard
-
Eli Schwartz
-
frederik＠ofb.net
-
Jens John
-
Leonid Isaev
-
Ralf Mardorf
-
Ralph Corderoy
-
WorMzy Tykashi