Bug 2510047

Summary:	can't modify file attributes in /etc at startup, with readonly-root
Product:	[Fedora] Fedora	Reporter:	Jacquelin Charbonnel <jacquelin.charbonnel>
Component:	sssd	Assignee:	sssd-maintainers <sssd-maintainers>
Status:	NEW ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	44	CC:	abokovoy, atikhono, jacquelin.charbonnel, lslebodn, pbrezina, sbose, ssorce, sssd-maintainers
Target Milestone:	---	Keywords:	Regression
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jacquelin Charbonnel 2026-08-01 17:12:19 UTC

In /usr/lib/systemd/system/sssd.service, we find : 

ExecStartPre=+-/bin/chown -f -R -H root:sssd /etc/sssd
ExecStartPre=+-/bin/chmod -f -R g+r /etc/sssd
ExecStartPre=+-/bin/chmod -f g+x /etc/sssd
ExecStartPre=+-/bin/chmod -f g+x /etc/sssd/conf.d
ExecStartPre=+-/bin/chmod -f g+x /etc/sssd/pki

It doesn't work if /etc is read only (with readonly-root for example).
Suggestion : add this line

files /etc/sssd

in /etc/rwtab


Reproducible: Always

Comment 1 Alexey Tikhonov 2026-08-02 08:15:23 UTC

Hi.

> ExecStartPre=+-/bin/chown -f -R -H root:sssd /etc/sssd
> ExecStartPre=+-/bin/chmod -f -R g+r /etc/sssd

'-' prefix tells to ignore failures and '-f' suppresses errors, so service will start.

What is the actual issue?
SSSD doesn't work because of wrong files ownership/permissions of config file?

Comment 2 Jacquelin Charbonnel 2026-08-02 09:34:00 UTC

Hi,
Start the service cause worrying lines in journald, giving the impression of a starting failure
(I'd verify in September if the service really starts, August is vacation time).
Thx

Comment 3 Simo Sorce 2026-08-03 14:07:00 UTC

@atikhono why is this even done on each startup?

This kind of file ownership should be defined in the RPM (so that rpm verify works correctly as well, and if some old version used a different ownership use a post-install scriptlet to fix the old permissions.

Comment 4 Lukas Slebodnik 2026-08-03 14:14:56 UTC

(In reply to Simo Sorce from comment #3)
> @atikhono why is this even done on each startup?
> 
> This kind of file ownership should be defined in the RPM (so that rpm verify
> works correctly as well, and if some old version used a different ownership
> use a post-install scriptlet to fix the old permissions.

IIRC `post-install scriptlet` does not work for ostree based distributions.

Comment 5 Alexey Tikhonov 2026-08-03 14:16:47 UTC

(In reply to Simo Sorce from comment #3)
> @atikhono why is this even done on each startup?
> 
> This kind of file ownership should be defined in the RPM (so that rpm verify
> works correctly as well, and if some old version used a different ownership
> use a post-install scriptlet to fix the old permissions.

It's done in RPM but it didn't work for rpm-ostree based systems.

Comment 6 Simo Sorce 2026-08-03 14:34:09 UTC

rpm-ostree should not need post install adjustments, if the file ownership is declared correctly in the files section it will be already correct on disk.

If this is done in post-install because the sssd group is allocated dynamically, then the obvious fix here is to get instead a fixed allocated id so that it is a known group instead.

After all SSSD is basically always installed so a fixed GID is justifiable.