-
Notifications
You must be signed in to change notification settings - Fork 256
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
2.10.1 sssd.service
permission error when accessing /etc/sssd/sssd.conf
#7784
Comments
Is g+x bit missing on /etc/sssd? (also see https://bugzilla.redhat.com/show_bug.cgi?id=2334868) I think it should be fixed via 2nd patch in #7783 |
I updated the permissions on
Now sssd throws a different error (progress!):
Now that sssd has gotten passed being unable to read the main config file, the logs in These now report the following:
I do not have much experience with sssd, but at a glance I would guess the cause has something to do with the following lines:
Could those "No such file or directory" errors be due to permission conflicts as well? |
Look for the reason in /var/log/sssd/sssd_co.champaign.il.us.log |
Looking at
(unfortunately Another is trouble with the
Is it possible that version 2.10.1 fails to load some cached values from 2.10.0? Did something change structurally in the way the keytab works? Or could this be another permission error?
P.S. My
|
what is the output of |
The output of
|
Trying again a few times, ldap_child.log is now populated. The error related to
|
No, those are different (though most probably one is a consequence of another). Could you please set
in the domain section of sssd.conf, stop sssd, clear /var/log/sssd/*, start sssd, match "Failed to get principal from keytab (sss_atomic_read_s() failed)" with corresponding part of 'ldap_child.log' using microseconds and post it? |
My apologies but the
|
Ok, I asked this but missed to read response properly, sorry.
So this ^^ is wrong.
(see 1614c5e) This is a bug in ostree-rs-ext -- see ostreedev/ostree-rs-ext#654 Until then you can add 'CAP_CHOWN CAP_DAC_OVERRIDE' back to sssd.service |
It's working (tentatively)! Specifically, I ran And added
This creates the override file So in short, the steps to get AD Domain logins working on bluefin-dx using version 2.10.1 of sssd:
The sudo chmod g+x step will be unnecessary once a release which includes patch #7783 is pushed and accepted. For the I need to test this on my coworker's laptop to see if it fixes the issue there as well. |
It is not "AD domain" specific.
You only need 'x' flag on folders, not on config files itself. |
Good catch!
This is good to know, the command I have passed on was As to
That seems to be incorporated into bootc here: containers/bootc#920 So when fedora / bluefin pulls in the following package: https://bodhi.fedoraproject.org/updates/FEDORA-2024-e7abdb1f24 The Thank you for all of your help on this! |
Would you happen to know when patch #7783 will be sent out to the rest of Fedora and be in a bodhi.fedoraproject.org/updates/ package? |
Thank you for the great write up. Just a small note about:
-- this specific issue is with rpm-ostree based systems. More traditional package based system had this covered properly in a spec-file. But this is a known "trap" that rpm-ostree can't propagate /etc and /var updates of underlying packages. And this is the main reason of all those (really undesirable) gimmicks with chmod/chown in sssd.service...
I hope no later than by the end of the month, maybe earlier. But not hard promises. |
The credit for that great write up goes to my coworker, he has been working on the communicating-with-bluefin side of this and attempting to get things working alongside me. His help has been instrumental. |
I am running into an issue where my sssd is breaking with version 2.10.1, it seems that the
sssd.service
no longer has the permissions to access the/etc/sssd/sssd.conf
file.Version 2.10.0
systemctl status sssd.service
Version 2.10.1
systemctl status sssd.service
Both the
sssd.conf
andsssd.service
files are regular files, nothing going on with sym links or the like (this is on 2.10.0, hencesssd.conf
is not group readable):If it helps, I am running BluefinDX which is an immutable file system which uses rpm-ostree for updates.
I am unsure why this occurring as the 2.10.1 version of the service sets the file to be group readable and its own group to sssd, but these are the logs.
The text was updated successfully, but these errors were encountered: