#2321 daemon FAILS to start with config file set to mode 400
Closed: Fixed None Opened 4 years ago by jhrozek.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 1089098

Description of problem:

On daemon start, refuses to start if config file is not writable. But as the
error messages show, the code is utterly confused and actually tries to open it
read-only and then bails when it's not writable.

Daemons are NEVER to attempt to modify their own configuration files, so
complaining about a non-writable file is illogical to begin with.

Version-Release number of selected component (if applicable):

1.9.2-82.el6

How reproducible:

always

Steps to Reproduce:
1. chmod 0400 /etc/sssd/sssd.conf
# ls -l -Z /etc/sssd/sssd.conf
-r--------. root root unconfined_u:object_r:etc_t:s0   /etc/sssd/sssd.conf
2. service sssd start
[FAILED]
3. chmod 0600 /etc/sssd/sssd.conf
# ls -l -Z /etc/sssd/sssd.conf
-rw-------. root root unconfined_u:object_r:etc_t:s0   /etc/sssd/sssd.conf
4. service sssd start
[OK]

Actual results:
from /var/log/sssd/sssd.log

(Thu Apr 17 22:47:08:633250 2014) [sssd] [perform_checks] (0x0020): File has
the wrong mode [0000400], expected [0000600].
(Thu Apr 17 22:47:08:633393 2014) [sssd] [check_and_open_readonly] (0x0020):
check_fd failed.
(Thu Apr 17 22:47:08:633424 2014) [sssd] [confdb_init_db] (0x0020): Permission
check on config file failed.
(Thu Apr 17 22:47:08:633463 2014) [sssd] [load_configuration] (0x0010): ConfDB
initialization has failed [Operation not permitted]
(Thu Apr 17 22:47:08:633555 2014) [sssd] [main] (0x0020): Cannot read
configuration file /etc/sssd/sssd.conf

Expected results:

successful startup every time.

Additional info:

knock some sense into the intern who wrote the perform_check code.

I thought that with the latest version of ding-lins we are going to utilize its ability to verify that the file has right permissions. Is this not the case? I have seen Simo's patch and was surprised by the scope. It should be one liner i.e. stop checking for one value and start checking for another.
I know we also check the domain sockets but is this even related?

blockedby: =>
blocking: =>
changelog: =>
coverity: =>
design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
review: True => 0
selected: =>
testsupdated: => 0

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.12 beta

Fields changed

owner: somebody => simo
patch: 0 => 1

resolution: => fixed
status: new => closed

Metadata Update from @jhrozek:
- Issue assigned to simo
- Issue set to the milestone: SSSD 1.12 beta

2 years ago

Login to comment on this ticket.

Metadata