#425 sssd does not start if sssd.conf is a symlink
Closed: Fixed None Opened 14 years ago by amcnabb.

SSSD is refusing to start because sssd.conf has permissions 644 instead of 600. In this situation, there is no sensitive information in sssd.conf, and the requirement that it have specific permissions is unreasonable. In fact, since this configuration file is in version control at our site, the default permission is 644, and it would be extremely easy for the file to accidentally get chmodded 644 again. I'm very worried because the system will hang at boot if the config file is chmodded 644 at any point. If there really has to be a permissions check (and I don't see any particular reason that there does), it would at least be better if it checked the permissions of /etc/sssd instead of /etc/sssd/sssd.conf, but I would really be happier if it didn't do either. Thanks.


sssd.conf can contain passwords, so it can't be readable by others.
Why can't your versioning system make sure the file stays 600 ?

Granted, I'm new to SSS, but I can't find anything in the documentation or HOWTO about putting passwords in sssd.conf. I really can't find any place where it can take a password.

With respect to permissions, Git only tracks the execute bit. If there's any way to configure it to track other permissions, too, I would love to know about it.

I only know of a few other programs that won't start if permissions are "wrong", and none of them are capable of hanging a system at startup. Maybe it could log error messages instead of crashing?

It turns out that sssd also crashes if /etc/sssd/sssd.conf is a symlink to a file which is 600 and owned by root:root.

Even stranger, I'm now getting this error on a machine without any symlinks or permission problems or anything:

[root@20potato ~]# service sssd start
Starting sssd: Cannot read config file /etc/sssd/sssd.conf, please check if permissions are 0600 and the file is owned by root.root
[FAILED]
[root@20potato ~]# ls -l /etc/sssd/sssd.conf
-rw------- 1 root root 2234 2010-03-18 17:09 /etc/sssd/sssd.conf
[root@20potato ~]#

Okay, that last one was caused by an unrelated bug (and a misleading error message from sssd). I'll open a bug report about that separately.

From sssd-ldap(5)

       ldap_default_bind_dn (string)
           The default bind DN to use for performing LDAP operations.

       ldap_default_authtok_type (string)
           The type of the authentication token of the default bind DN. The
           only currently supported value is "password".

       ldap_default_authtok (string)
           The authentication token of the default bind DN. Only clear text
           passwords are currently supported.

If LDAP communications need to be performed by using a particular bind DN, the password is stored in plaintext in the sssd.conf as

ldap_default_authtok_type = password
ldap_default_authtok = V3rySekret

Because of this, we mandate that the file not be world-readable.

We also disallow symlinks because we want to ensure that the sssd.conf is on the correct filesystem at boot time, and because it makes it easier to secure the file with SELinux.

I'm closing this bug as WONTFIX, because this is functioning as explicitly designed.

resolution: => wontfix
status: new => closed

Seriously? No other program seems to be so controlling about this sort of stuff. I'm scared to use sssd if there's a good chance it's going to make the system hang at startup.

Can't you trust the user just a little bit? Even SELinux has some tools built-in for setting labels on files that are in different locations.

Requiring that the file not be world-readable just because it might have a password in it (but probably doesn't) seems a little heavy handed, but not allowing it to be a symlink just seems arbitrary. If I put the file on the wrong filesystem, or if I don't set the SELinux labels correctly, then that's my problem. Having sssd crash doesn't make the problem any easier to track down, and I've never seen any other daemon do this.

Would you please reconsider, at least the symlink part? I'd much rather have sssd trust the sysadmin a little bit, just like all other system services do. I really can't think of any situation where sssd crashing would help me, and it's definitely getting in the way.

Otherwise, sssd has been very easy to configure and use. Thanks for all of your great work on the project.

resolution: wontfix =>
status: closed => reopened

We are evaluating the symlink problem, but I am curious why you say sssd crashes ?
Normally sssd just exits in this situtaion.
Furthermore sssd not starting should never cause system startup issues. Of course users serverd via sssd will not be available but all system users and root which are in /etc/passwd should work without issues, are you seeing problems there ?

Hmm. Now that I think about it more, I guess if sss can't start at boot, lookups will just fail instead of hanging. I have noticed that if a user is using GNOME, then their session will hang if sssd isn't working, which can still be a big problem but isn't as bad as the system hanging on boot (which is what happens with nss_ldap whenever anything goes slightly wrong).

Are you absolutely sure about session hangs? Because that is not the behavior that I see.

Eating my own dogfood, I am running with an LDAP and Kerberos provided user on GNOME on Fedora 12. I regularly shut down my SSSD or restart it in order to test new changes. I've never seen a hung GNOME session from this.

I do see failures in username lookups, such as seeing "No such ID!" if I try to open a new shell while SSSD is off, but never a session hang.

Please open a new bug if you see such behavior with exact steps to reproduce.

Steve, I have seen a strange behavior in the past when the SSSD was in a stale condition. Usually during updates so I can't say for sure but I think I observed behavior that seemed as a hang, actually it was not it was a long timeout (3-4 minutes) on every operation that required name lookup.
I will test it on my CSB but before I need to make sure nobody is waiting to me to make something urgent since testing can force me offline for some time.

If there is a gnome session hanging bug please open a separate bug.
Trac is not a discussion forum.

It will be a few days before I can get to it, but I'll open a separate bug report about session hangs. I agree that this bug report should focus on the symlink thing (which is just silly and doesn't actually protect from anything) and the permissions thing. A few thoughts about permissions:

1) Postfix puts passwords in a separate file, as does Apache with SSL keys. I'm sure there are many other examples of this general model. These systems enforce permissions for the sensitive files but not for the general configiguration. Not only does this make system administration easier, it also means that people are less likely to accidentally post sensitive information in bug reports.

2) Other systems, like libvirt, named, and cups set their configuration to be unreadable by default, but they don't fail if the permissions are changed by the administrator.

3) It's not pretty, but maybe there could be a new command-line option: --i-swear-i-dont-have-any-passwords-in-the-config-please-just-treat-me-like-an-adult-and-start.

Okay, so (3) isn't a serious suggestion, but I think (1) would be a really good idea. If anything, I think it actually improves security.

We agree that we will allow symlinked sssd.conf.

There is an ongoing discussion on how to handle passwords and permissions on the sssd-devel mailing list, beginning here: https://fedorahosted.org/pipermail/sssd-devel/2010-March/002970.html

Further discussion on that topic should be done by email, and a new enhancement ticket will be opened to detail the changes once they are agreed on.

milestone: NEEDS_TRIAGE => SSSD 1.2
owner: somebody =>
status: reopened => new

Fields changed

owner: => sgallagh

Replying to [comment:14 sgallagh]:

We agree that we will allow symlinked sssd.conf.

There is an ongoing discussion on how to handle passwords and permissions on the sssd-devel mailing list, beginning here: https://fedorahosted.org/pipermail/sssd-devel/2010-March/002970.html

Further discussion on that topic should be done by email, and a new enhancement ticket will be opened to detail the changes once they are agreed on.

Changing the summary to reflect this and stealing from Stephen.

owner: sgallagh => jhrozek
summary: sssd.conf required to have permissions 0600 => sssd does not start if sssd.conf is a symlink

Stealing it back. I ended up fixing this as a side-effect of another patch I was working on. The patch is now on the sssd-devel mailing list.

owner: jhrozek => sgallagh
status: new => assigned

Fixed by 55a0f22

fixedin: => 1.2.0
resolution: => fixed
status: assigned => closed

Fields changed

rhbz: => 0

Metadata Update from @amcnabb:
- Issue assigned to sgallagh
- Issue set to the milestone: SSSD 1.2.0

7 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1467

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata