Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1412170 - sssd segfaults when /etc/sssd/conf.d permissions are incorrect
Summary: sssd segfaults when /etc/sssd/conf.d permissions are incorrect
Keywords:
Status: CLOSED DUPLICATE of bug 1396485
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.2
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: SSSD Maintainers
QA Contact: Steeve Goveas
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-11 12:45 UTC by Jason
Modified: 2017-01-11 14:57 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-11 13:35:40 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Jason 2017-01-11 12:45:42 UTC
Description of problem:

After updating sssd from 1.13.0-40.el7_2.12 to 1.14.0-43.el7_3.4, sssd fails to start and journalctl indicates a segfault. /var/log/sssd/sssd.log indicates a permission denied error with /etc/sssd/sssd.conf.

Version-Release number of selected component (if applicable):
1.14.0-43.el7_3.4

How reproducible:
Always

Steps to Reproduce:
1. systemctl start sssd
2.
3.

Actual results:

[root@odt-control ~]# systemctl start sssd
Job for sssd.service failed because the control process exited with error code. See "systemctl status sssd.service" and "journalctl -xe" for details.

-- Subject: Unit sssd.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit sssd.service has begun starting up.
Jan 11 07:20:53 odt-control sssd[35096]: Starting up
Jan 11 07:20:53 odt-control sssd[be[dc.example.com]][35097]: Starting up
Jan 11 07:20:53 odt-control kernel: sssd_be[35097]: segfault at 58 ip 00007fb44f0b22a2 sp 00007fff4245bbe0 error 4 in libsss_ad.so[7fb44f091000+34000]
Jan 11 07:20:53 odt-control sssd[be[dc.example.com]][35098]: Starting up
Jan 11 07:20:53 odt-control kernel: sssd_be[35098]: segfault at 58 ip 00007f6abff4d2a2 sp 00007ffe3d740280 error 4 in libsss_ad.so[7f6abff2c000+34000]
Jan 11 07:20:55 odt-control sssd[be[dc.example.com]][35099]: Starting up
Jan 11 07:20:55 odt-control kernel: sssd_be[35099]: segfault at 58 ip 00007f44c1a482a2 sp 00007fffb066ce60 error 4 in libsss_ad.so[7f44c1a27000+34000]
Jan 11 07:20:58 odt-control sssd[ssh][35103]: Starting up
Jan 11 07:20:58 odt-control sssd[nss][35101]: Starting up
Jan 11 07:20:58 odt-control sssd[pam][35102]: Starting up
Jan 11 07:20:58 odt-control sssd[autofs][35104]: Starting up
Jan 11 07:20:58 odt-control sssd[ssh][35105]: Starting up
Jan 11 07:20:58 odt-control sssd[nss][35106]: Starting up
Jan 11 07:20:58 odt-control sssd[pam][35107]: Starting up
Jan 11 07:20:58 odt-control sssd[autofs][35108]: Starting up
Jan 11 07:20:59 odt-control sssd[be[dc.example.com]][35109]: Starting up
Jan 11 07:20:59 odt-control kernel: sssd_be[35109]: segfault at 58 ip 00007fa41fe9e2a2 sp 00007ffe97ee7b00 error 4 in libsss_ad.so[7fa41fe7d000+34000]
Jan 11 07:20:59 odt-control sssd[35096]: Exiting the SSSD. Could not restart critical service [dc.example.com].
Jan 11 07:20:59 odt-control systemd[1]: sssd.service: control process exited, code=exited status=1
Jan 11 07:20:59 odt-control systemd[1]: Failed to start System Security Services Daemon.

-- Subject: Unit sssd.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit sssd.service has failed.
--
-- The result is failed.
Jan 11 07:20:59 odt-control systemd[1]: Unit sssd.service entered failed state.
Jan 11 07:20:59 odt-control systemd[1]: sssd.service failed.
Jan 11 07:20:59 odt-control polkitd[972]: Unregistered Authentication Agent for unix-process:35090:17152243 (system bus name :1.27, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.US.UTF-8) (disconnected from bus)


Here are my permissions:


[root@odt-control ~]# ls -laR /etc/sssd
/etc/sssd:
total 16
drwx--x--x.  3 sssd sssd   35 Jan 10 21:45 .
drwxr-xr-x. 85 root root 8192 Jan 10 21:38 ..
drwx--x--x.  2 sssd sssd    6 Dec  6 22:44 conf.d
-rw-------.  1 root root  569 Jan  9 07:49 sssd.conf

/etc/sssd/conf.d:
total 0
drwx--x--x. 2 sssd sssd  6 Dec  6 22:44 .
drwx--x--x. 3 sssd sssd 35 Jan 10 21:45 ..


# var/log/sssd/sssd.log

(Wed Jan 11 07:20:53:292126 2017) [sssd] [sss_ini_get_config] (0x0020): Config merge error: Permission denied opening /etc/sssd/conf.d.
(Wed Jan 11 07:20:59 2017) [sssd] [monitor_restart_service] (0x0010): Process [dc.example.com], definitely stopped!


Expected results:

That sssd starts successfully.

I did some searching but its not clear what the permissions should be. So when it fails here, it would be convenient if journalctl or /var/log/sssd/sssd.log displayed what the correct permissions should be. Also journalctl should mention whats in sssd.log instead of segfault.

Additional info:

This is on CentOS 7.2 servers (not sure about RHEL).

Comment 1 Jason 2017-01-11 12:47:37 UTC
Sorry, the Description of Problem should read:

.../var/log/sssd/sssd.log indicates a permission denied error with /etc/sssd/conf.d.

Comment 2 Lukas Slebodnik 2017-01-11 12:51:44 UTC
I not think that crash is related to this directory crash is in sssd_be.
And this process does not touch it.

I would say it's a duplicate of https://fedorahosted.org/sssd/ticket/3234 BZ1392444.

it's caused by id_provider = ad and auth_provider = krb5.

Could you share your sssd.conf?

Comment 3 Lukas Slebodnik 2017-01-11 12:53:18 UTC
And about conf.d

Could you provide an output of following commands:
sh# ls -ld /etc/sssd/conf.d
sh# rpm -V sssd-common

Comment 4 Jason 2017-01-11 13:08:46 UTC
Ah yes, the permissions thing was a red herring. auth_provider = krb5 was the problem.  I removed it from sssd.conf and sssd starts up fine.  

I left id_provider = ad in place and it works OK. Should I remove the id_provider line as well?

Comment 5 Lukas Slebodnik 2017-01-11 13:14:47 UTC
(In reply to Jason from comment #4)
> Ah yes, the permissions thing was a red herring. auth_provider = krb5 was
> the problem.  I removed it from sssd.conf and sssd starts up fine.  
>
auth_provider is inherited from id_provider by defualt
 
> I left id_provider = ad in place and it works OK. Should I remove the
> id_provider line as well?
NO.

and could you provide an output of requested commands for issue with directory?

Comment 6 Jason 2017-01-11 13:19:42 UTC
# ls -ld /etc/sssd/conf.d
drwx--x--x. 2 sssd sssd 6 Jan 11 08:01 /etc/sssd/conf.d
# rpm -V sssd-common
#
# rpm -qa sssd
sssd-1.14.0-43.el7_3.4.x86_64

Comment 7 Jason 2017-01-11 13:34:13 UTC
Just an FYI, removing auth_provider = krb5 breaks authentication on servers running an older sssd (1.13.0-40.el7_2.12), so this workaround isn't backward compatible. Explicitly saying auth_provider = ad breaks it as well.  Its fine, I just have to work around it in puppet until I get all of our servers updated to sssd 1.14.

Comment 8 Lukas Slebodnik 2017-01-11 13:35:40 UTC

*** This bug has been marked as a duplicate of bug 1396485 ***

Comment 9 Lukas Slebodnik 2017-01-11 13:38:57 UTC
(In reply to Jason from comment #7)
> Just an FYI, removing auth_provider = krb5 breaks authentication on servers
> running an older sssd (1.13.0-40.el7_2.12), so this workaround isn't
> backward compatible. Explicitly saying auth_provider = ad breaks it as well.
> Its fine, I just have to work around it in puppet until I get all of our
> servers updated to sssd 1.14.

Auth_provider ad should work 1.13. You might try to find a reason why auth_provider ad does not work https://fedorahosted.org/sssd/wiki/Troubleshooting

But fix for BZ1396485 should be released soon and auth_provider = krb5 should work with id_provider ad also with 1.14

Comment 10 Jakub Hrozek 2017-01-11 13:42:10 UTC
(In reply to Lukas Slebodnik from comment #9)
> (In reply to Jason from comment #7)
> > Just an FYI, removing auth_provider = krb5 breaks authentication on servers
> > running an older sssd (1.13.0-40.el7_2.12), so this workaround isn't
> > backward compatible. Explicitly saying auth_provider = ad breaks it as well.
> > Its fine, I just have to work around it in puppet until I get all of our
> > servers updated to sssd 1.14.
> 
> Auth_provider ad should work 1.13. You might try to find a reason why
> auth_provider ad does not work
> https://fedorahosted.org/sssd/wiki/Troubleshooting
> 

most probably because of ccache validation -> krb5_validate=false should work around the issue. I don't know why would 1.14 work, but maybe disabling validation on the old serves might help (please read the description of krb5_validate in the man pages, though).

If you were already using krb5 auth provider, then you don't lose anything by going with ad auth provider and disabled validation as krb5 auth provider doesn't use the validation by default.

> But fix for BZ1396485 should be released soon and auth_provider = krb5
> should work with id_provider ad also with 1.14

Comment 11 Lukas Slebodnik 2017-01-11 13:47:48 UTC
(In reply to Jakub Hrozek from comment #10)
> (In reply to Lukas Slebodnik from comment #9)
> > (In reply to Jason from comment #7)
> > > Just an FYI, removing auth_provider = krb5 breaks authentication on servers
> > > running an older sssd (1.13.0-40.el7_2.12), so this workaround isn't
> > > backward compatible. Explicitly saying auth_provider = ad breaks it as well.
> > > Its fine, I just have to work around it in puppet until I get all of our
> > > servers updated to sssd 1.14.
> > 
> > Auth_provider ad should work 1.13. You might try to find a reason why
> > auth_provider ad does not work
> > https://fedorahosted.org/sssd/wiki/Troubleshooting
> > 
> 
> most probably because of ccache validation -> krb5_validate=false should
> work around the issue. I don't know why would 1.14 work, but maybe disabling
> validation on the old serves might help (please read the description of
> krb5_validate in the man pages, though).
> 
> If you were already using krb5 auth provider, then you don't lose anything
> by going with ad auth provider and disabled validation as krb5 auth provider
> doesn't use the validation by default.
> 
It does not explain why "auth_provider ad" works with 1.14 and does not work with 1.13

krb5_validate is true in both cases for AD

Comment 12 Jason 2017-01-11 13:50:11 UTC
For completeness, here is my sssd.conf BEFORE making any changes today:

# cat /etc/sssd/sssd.conf
[sssd]
domains = dc.example.com
config_file_version = 2
services = nss, pam, ssh, autofs

[domain/dc.example.com]
ad_server = ad01.dc.example.com
ad_domain = dc.example.com
krb5_realm = DC.EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli
cache_credentials = false
id_provider = ad
auth_provider = krb5
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
fallback_homedir = /home/%u
access_provider = ad
use_fully_qualified_names = False
ad_gpo_access_control = disabled
client_idle_timeout = 76
enumerate = true

Comment 13 Jason 2017-01-11 13:59:06 UTC
Yes, disabling validation with krb5_validate=false fixed it so that I could apply the workaround on the old servers.

Comment 14 Lukas Slebodnik 2017-01-11 14:57:50 UTC
(In reply to Jason from comment #13)
> Yes, disabling validation with krb5_validate=false fixed it so that I could
> apply the workaround on the old servers.

You should rather find out why validation failed with old sssd.
"krb5_validate=false" should be used just for testing purposes.
Especially because you have a keytab; I assume machine was enrolled with realmd
due to option realmd_tags.


Note You need to log in before you can comment on or make changes to this bug.