Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pam_env should be marked as 'optional' #202

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

trevor-vaughan
Copy link
Contributor

We don't want the session stack of our PAM configuration to fail if
pam_env fails for some reason.

Fixes #201

We don't want the `session` stack of our PAM configuration to fail if
pam_env fails for some reason.

Fixes Scribery#201
@coveralls
Copy link

Coverage Status

Coverage remained the same at 38.743% when pulling df889cc on trevor-vaughan:pam_env-fix into 16f9a71 on Scribery:master.

@spbnick
Copy link
Member

spbnick commented Aug 22, 2018

Could you please describe a situation where this would be useful, and having "required" would break things? I haven't thought this through or researched, was just copying Debian setup, where reading /etc/default/locale is required, and would appreciate your POV.

@trevor-vaughan
Copy link
Contributor Author

@spbnick Though it should be extremely rare, required means that an error in the underlying library could cause you to never login while optional means that if the underlying library fails, continue on and just log an error/warning.

So, in reality, should this ever cause a problem with this particular call...probably not, but it could so why not be safe?

@spbnick
Copy link
Member

spbnick commented Aug 22, 2018

Thank you, @trevor-vaughan. Well, in the case of tlog-rec, at the moment it might result in tlog-rec producing a warning about seeing ASCII, and assuming it's UTF-8, or refusing to work if for some reason something else is set. In the future it might result in the I/O being converted to UTF-8 from the wrong encoding and being (partially) unsearchable.

@trevor-vaughan
Copy link
Contributor Author

@spbnick I guess the question is, should either of those situations cause a login to completely fail? If the answer is, yes, tlog probably needs its own PAM module.

@spbnick
Copy link
Member

spbnick commented Aug 22, 2018

I think the right fix is for Fedora/RHEL to provide the locale environment via environment variables (as Debian does), instead of relying on the program being started at login to be a shell, knowing about /etc/locale.conf, and being able to interpret it.

I think I understand your concern with keeping logins working at all times, but I would prefer the suggested workaround to break as soon as possible, producing a relevant error message ("cannot read /etc/locale.conf", or such), instead of leading to tlog-rec-session not working and producing an error message which would need to be researched, or worse, working incorrectly.

@trevor-vaughan
Copy link
Contributor Author

@spbnick Ok, in that case, you need to update your instructions such that the root user can jump around this condition since you'll break that user's logins as well if this fails for some reason.

@spbnick
Copy link
Member

spbnick commented Aug 22, 2018

I understand your apprehension, but Debian doesn't have a problem with requiring pam_env for root, so I wouldn't either, at least for the time being. I would really like to have this issue raised with Fedora folks.

@trevor-vaughan
Copy link
Contributor Author

Sure, link me over to the issue and I'll +1 it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

pam_env should be 'optional' in the suggested PAM configuration
3 participants