pam module fails when "service" is a symlink and "backup: yes"

Question

pam module fails when "service" is a symlink and "backup: yes"

jamescassell opened this issue 7 years ago · 12 comments

This issue is similar to ansible/ansible#6986

By default, on RHEL6, /etc/pam.d/system-auth is a symlink to /etc/pam.d/system-auth-ac. After running this role, system-auth ends up as a file rather than a symlink.

I'll send in a patch for this issue.

Answer 1 · 2017-12-01T19:53:37.000Z

You dont need to go to this extreme but you're welcomed to submit a PR that switches out the custom PAM module we have here to use the one that is now part of the upstream. I think we'd still take the patch but if you feel like doing a lil extra, I wont stop you ;)

Answer 2 · 2017-12-01T20:23:17.000Z

Breaking the link is a feature. It precludes losing your configs if someone runs authconfig.

Answer 3 · 2017-12-01T22:55:56.000Z

The error only manifests itself when "backup: yes" is set. Otherwise, it writes through to the linked file. At the very least it needs an option to follow/not follow a link.

I've patched the custom pam module locally, but I'm exploring the change suggested by @defionscode (using the upstream pamd module)

Answer 4 · 2017-12-04T14:33:08.000Z

The upstream pamd module does not support "backup." I've created a patch for this specific issue with the custom pam module, and also a separate patch that switches to the upstream pamd module. I'll send them in after I've tested them a bit more, hopefully today.

Answer 5 · 2017-12-04T14:43:40.000Z

Hmm alright, I may look into making a PR for the upstream pamd module to add backup support. I really appreciate your help.

Answer 6 · 2017-12-05T23:52:59.000Z

Do you want one pull request with all my various fixes, our should I break them out by issue?

Answer 7 · 2017-12-06T00:00:45.000Z

It's your call but separate may be better in that issues with one thing aren't as likely to hold up the other bits. Either way we'll work through it.

…

On Tue, Dec 5, 2017 at 6:53 PM James Cassell ***@***.***> wrote: Do you want one pull request with all my various fixes, our should I break them out by issue? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/MindPointGroup/RHEL6-STIG/issues/119#issuecomment-349481198>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEcrYgLqFx5n9elkeKen79vCyhzXk081ks5s9ddcgaJpZM4Qyvrm> .

Answer 8 · 2017-12-07T18:15:09.000Z

@jamescassell thank you for your contributions. I believe you still have on incoming PR. I'll close this issue once that has been submitted/accepted.

Answer 9 · 2017-12-07T18:36:00.000Z

Yes. Hopefully today. Thanks for merging my PRs!

Answer 10 · 2017-12-07T21:00:30.000Z

any preference as to whether the custom pam module should be removed as part the PR switching to the upstream pamd module? I've verified that the upstream pamd module behaves identically to the custom one, so far as the RHEL6-STIG projects usage of it, with the exception of not having "backup" support.

Answer 11 · 2017-12-07T21:48:43.000Z

I'm fine with removing it, worst case we can always go back into commit history to grab it should we need to.

Answer 12 · 2017-12-08T15:45:10.000Z

Turns out this issue wasn't caused by the custom pam module in cat2.yml or cat3.yml, but rather the 'replace' module in cat1.yml. That fix has already been merged. I was thrown off by the fact that the only call to the pam module with "backup:yes" was for system-auth, and assumed those conditions were causing the system-auth symlink to turn into a file. After swapping out the pam module for pamd, I identified the real issue of the replace module changing the symlink to a file. My PR still stands for switching to the official pamd module, though. I should have a few other fixes incoming, as well. Thanks for being responsive to my PRs!