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

RHEL-08-020040/41 needs additional configuration. #107

Closed
jmalpede opened this issue Jun 20, 2022 · 5 comments
Closed

RHEL-08-020040/41 needs additional configuration. #107

jmalpede opened this issue Jun 20, 2022 · 5 comments
Labels
bug Something isn't working

Comments

@jmalpede
Copy link

tmux is not fully implemented after "MEDIUM | RHEL-08-020041 | PATCH | RHEL 8 must ensure session control is automatically started at shell initialization" has been applied. So, tmux does not get launched on remote sessions.

Expected Behavior
tmux should be running for session control.

Actual Behavior
tmux is not running.

Control(s) Affected
What controls are being affected by the issue: RHEL-08-020041

Possible Solution
Append the line: [ -n "$PS1" -a -z "$TMUX" ] && exec tmux at the end of the /etc/bashrc file to enable session contol for remote sessions.

@jmalpede jmalpede added the bug Something isn't working label Jun 20, 2022
@matthew-willis
Copy link
Contributor

I've attempted the presented solution above and when a non-elevated user session locked, I still run into the issue where user is unable to access the tty - error Permission Denied .

Now, if I log in as root and lock the TMUX session, I am able to log back in and access TMUX session.

I tried several other things in this venture, by turning off SELINUX, attempted to set permissions of the tty sessions (not sure if that's the right approach) and few other items. In the end, non-elevated accounts cannot access TMUX sessions after the session is locked.

This bug right now is quite annoying and I currently have this STIG ID turned off in the meantime.

@matthew-willis
Copy link
Contributor

@uk-bolly I think I found the resolve.

The error that kept showing up was the 'vlock' did not have the permissions to open /etc/init.d/system-auth since system-auth was included /etc/pam.d/vlock file.

Upon further checking, I noticed that both password-auth and system-auth are set to 0640 vs 0644. I may have missed it somewhere, but is 0640 the default permission scheme for these files? As soon as I set 0644, restarted sssd, I was successful in locking/unlocking with a user non-elevated credentials.

Thoughts?

@matthew-willis
Copy link
Contributor

#122 Recommend this issue is closed. TMUX sessions work after updating permissions on /etc/pam.d/system-auth file.

@uk-bolly
Copy link
Member

hi @jmalpede

Thank you as always for raising issues. I believe we may have found a fix for this as noted by @matthew-willis. This should now be included in the latest devel release.
Please let us know if this is not working for you?

Many thanks again

uk-bolly

@georgenalen
Copy link
Contributor

This issue is fixed in release 2.6.0, thank you for opening the issue!

-George

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants