[Bug 2299733] New: logrotate service will fail to start due to improper permissions on /var/log/sssd directory
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
Bug ID: 2299733 Summary: logrotate service will fail to start due to improper permissions on /var/log/sssd directory Product: Fedora Version: rawhide Hardware: x86_64 OS: Linux Status: NEW Component: sssd Keywords: Regression Severity: high Assignee: sssd-maintainers@lists.fedoraproject.org Reporter: sponix2ipfw@gmail.com QA Contact: extras-qa@fedoraproject.org CC: abokovoy@redhat.com, atikhono@redhat.com, lslebodn@redhat.com, mzidek@redhat.com, pbrezina@redhat.com, sbose@redhat.com, ssorce@redhat.com, sssd-maintainers@lists.fedoraproject.org Target Milestone: --- Classification: Fedora
I see that the logrotate service has failed to start from within cockpit. In there it explains that this is due to improper permissions on /var/log/sssd directory. After a sudo chmod 755 /var/log/sssd I can start the logrotate service without issues. Pretty sure what I've done to resolve this is take the permissions from drwxrwxr-x to drwxr-xr-x on this directory.
Reproducible: Always
Steps to Reproduce: 1.Apply system updates that include sssd, have a look at services in cockpit 2.after seeing the logrotate service failed to start using sudo chmod 755 /var/log/sssd 3.clear the error, and start logrotate and it works as it should Actual Results: Well, the steps above get logrotate running again. I am not sure how this may effect the sssd system itself though
Expected Results: it is expected to see logrotate service running without the need to use sudo chmod 755 /var/log/sssd
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
Alexey Tikhonov atikhono@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(sponix2ipfw@gmail | |.com) Doc Type|--- |If docs needed, set a value
--- Comment #1 from Alexey Tikhonov atikhono@redhat.com ---
In there it explains that this is due to improper permissions on /var/log/sssd directory.
Could you please quote error message/log?
what I've done to resolve this is take the permissions from drwxrwxr-x to drwxr-xr-x on this directory
Depending on specific configuration, SSSD might need this folder to be group-writeable.
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
sponix2ipfw@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(sponix2ipfw@gmail | |.com) |
--- Comment #2 from sponix2ipfw@gmail.com --- logrotate error: skipping "/var/log/sssd/sssd_kcm.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
Alexey Tikhonov atikhono@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(sponix2ipfw@gmail | |.com)
--- Comment #3 from Alexey Tikhonov atikhono@redhat.com --- Could you please check if addition of a line ``` su sssd sssd ``` to `/etc/logrotate.d/sssd` (inside {}, for example after "compress" line) resolves an issue for you?
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
Alexey Tikhonov atikhono@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|sssd-maintainers@lists.fedo |atikhono@redhat.com |raproject.org |
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
sponix2ipfw@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(sponix2ipfw@gmail | |.com) |
--- Comment #4 from sponix2ipfw@gmail.com --- (In reply to Alexey Tikhonov from comment #3)
Could you please check if addition of a line
su sssd sssdto `/etc/logrotate.d/sssd` (inside {}, for example after "compress" line) resolves an issue for you?
root@sponix:/etc/logrotate.d# cat sssd /var/log/sssd/*.log { weekly missingok notifempty sharedscripts rotate 2 compress delaycompress su sssd sssd postrotate /bin/kill -HUP `cat /var/run/sssd.pid 2>/dev/null` 2> /dev/null || true /bin/pkill -HUP sssd_kcm 2> /dev/null || true endscript }
within cockpit it no longer has the permission error given prior. But it still doesn't actually keep the logrotate service running either.
8:23 PM Finished logrotate.service - Rotate log files. systemd 8:23 PM logrotate.service: Deactivated successfully. systemd 8:23 PM Starting logrotate.service - Rotate log files...
Maybe this is a user error. I feel that logrotate service is supposed to keep running. Is this wrong of me?
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
--- Comment #5 from sponix2ipfw@gmail.com --- (In reply to Alexey Tikhonov from comment #1)
In there it explains that this is due to improper permissions on /var/log/sssd directory.
Could you please quote error message/log?
what I've done to resolve this is take the permissions from drwxrwxr-x to drwxr-xr-x on this directory
Depending on specific configuration, SSSD might need this folder to be group-writeable.
I can get you any logging you would like to see. Just give me a command to dig it up, and I'll attach it.
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
Alexey Tikhonov atikhono@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jamacku@redhat.com Flags| |needinfo?(jamacku@redhat.co | |m)
--- Comment #6 from Alexey Tikhonov atikhono@redhat.com --- (In reply to sponix2ipfw from comment #4)
(In reply to Alexey Tikhonov from comment #3)
Could you please check if addition of a line
su sssd sssdto `/etc/logrotate.d/sssd` (inside {}, for example after "compress" line) resolves an issue for you?
root@sponix:/etc/logrotate.d# cat sssd /var/log/sssd/*.log { weekly missingok notifempty sharedscripts rotate 2 compress delaycompress su sssd sssd postrotate /bin/kill -HUP `cat /var/run/sssd.pid 2>/dev/null` 2> /dev/null || true /bin/pkill -HUP sssd_kcm 2> /dev/null || true endscript }
within cockpit it no longer has the permission error given prior. But it still doesn't actually keep the logrotate service running either.
8:23 PM Finished logrotate.service - Rotate log files. systemd 8:23 PM logrotate.service: Deactivated successfully. systemd 8:23 PM Starting logrotate.service - Rotate log files...
Maybe this is a user error. I feel that logrotate service is supposed to keep running. Is this wrong of me?
Frankly, I don't know.
Jan, could you please help here?
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
Jan Macku jamacku@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jamacku@redhat.co | |m) |
--- Comment #7 from Jan Macku jamacku@redhat.com --- I think that the following change might be the root cause of your issue:
https://github.com/logrotate/logrotate/pull/560 https://github.com/logrotate/logrotate/commit/47f79e71b8e9f723b83081c3ddf742...
Change is included in logrotate-3.22.0
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
Alexey Tikhonov atikhono@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(jamacku@redhat.co | |m)
--- Comment #8 from Alexey Tikhonov atikhono@redhat.com --- Jan,
(1) is logrotate service supposed to keep running all the time or is behavior mentioned in comment 4 - expected?
(2) do you think my proposal in comment 3 is a proper solution when log dir is non-root-group writable?
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
Jan Macku jamacku@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jamacku@redhat.co | |m) |
--- Comment #9 from Jan Macku jamacku@redhat.com ---
(1) is logrotate service supposed to keep running all the time or is behavior mentioned in comment 4 - expected?
Rotation is based on the systemd timer. By default, it happens once per day.
(2) do you think my proposal in comment 3 is a proper solution when log dir is non-root-group writable?
Yes, this should be the way to go. From the man page:
``` If the user/group you specify here does not have sufficient privilege to make files with the ownership you've specified in a create directive, it will cause an error. If logrotate runs with root privileges, it is recommended to use the su directive to rotate files in directories that are directly or indirectly in control of non-privileged users. ```
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
--- Comment #10 from Alexey Tikhonov atikhono@redhat.com --- (In reply to Jan Macku from comment #9)
(1) is logrotate service supposed to keep running all the time or is behavior mentioned in comment 4 - expected?
Rotation is based on the systemd timer. By default, it happens once per day.
(2) do you think my proposal in comment 3 is a proper solution when log dir is non-root-group writable?
Yes, this should be the way to go. From the man page:
Thank you for the confirmation.
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
Alexey Tikhonov atikhono@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
--- Comment #11 from Alexey Tikhonov atikhono@redhat.com --- Upstream PR: https://github.com/SSSD/sssd/pull/7512
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
Alexey Tikhonov atikhono@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |POST
--- Comment #12 from Alexey Tikhonov atikhono@redhat.com --- Pushed PR: https://github.com/SSSD/sssd/pull/7512
* `master` * e4ae4d6129e85fe99bbb82438ed90352400ecdf3 - BUILD: configure logrotate to work with non-root-group writable folder
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
Christian Stadelmann fedora@genodeftest.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fedora@genodeftest.de Link ID| |Github SSSD/sssd/pull/7512
--- Comment #13 from Christian Stadelmann fedora@genodeftest.de --- Any chance we can get an upstream release so we can get this fix in Fedora 41?
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
--- Comment #14 from Alexey Tikhonov atikhono@redhat.com --- *** Bug 2315854 has been marked as a duplicate of this bug. ***
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
Jan Macku jamacku@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |seanmottles@posteo.net
--- Comment #15 from Jan Macku jamacku@redhat.com --- *** Bug 2316165 has been marked as a duplicate of this bug. ***
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
Jan Macku jamacku@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|rawhide |41
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
Timothée Ravier travier@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |travier@redhat.com
--- Comment #16 from Timothée Ravier travier@redhat.com --- Gentle ping here. It would be great to get this in Fedora 41 before the freeze next week. Thanks
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
Alexey Tikhonov atikhono@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed In Version| |sssd-2.10.0-1.fc41 Status|POST |MODIFIED
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
--- Comment #17 from Fedora Update System updates@fedoraproject.org --- FEDORA-2024-73827b9035 (sssd-2.10.0-1.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-73827b9035
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|MODIFIED |ON_QA
--- Comment #18 from Fedora Update System updates@fedoraproject.org --- FEDORA-2024-73827b9035 has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-73827b9035` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-73827b9035
See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
https://bugzilla.redhat.com/show_bug.cgi?id=2299733
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |ERRATA Status|ON_QA |CLOSED Last Closed| |2024-10-17 23:11:45
--- Comment #20 from Fedora Update System updates@fedoraproject.org --- FEDORA-2024-73827b9035 (sssd-2.10.0-1.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
sssd-maintainers@lists.fedoraproject.org
-
bugzilla＠redhat.com