SUSE has issued an advisory on July 30: http://lists.suse.com/pipermail/sle-security-updates/2018-July/004360.html The upstream announcement has a commit fix link for 1.13.x: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/XUCDLKDVH7HZKPSJ7GEJAVNZS5CW35EK/ Mageia 5 and Mageia 6 are also affected.
Whiteboard: (none) => MGA6TOO
Assigning to all packagers collectively, since there is no registered maintainer for this package. CC'ing daviddavid
Assignee: bugsquad => pkg-bugsCC: (none) => geiger.david68210, marja11
openSUSE has issued an advisory for this today (August 10): https://lists.opensuse.org/opensuse-updates/2018-08/msg00071.html
Done for Cauldron and also for mga6!
Thanks David! Advisory: ======================== Updated sssd packages fix security vulnerability: The UNIX socket that is used for communication between the sudo utility and the sssd-sudo responder had its permissions set to world-readable and writable, which means that anyone who can send a message using the same raw protocol that sudo and SSSD use can read the sudo rules available for any user (CVE-2018-10852). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10852 https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/XUCDLKDVH7HZKPSJ7GEJAVNZS5CW35EK/ https://lists.opensuse.org/opensuse-updates/2018-08/msg00071.html ======================== Updated packages in core/updates_testing: ======================== sssd-1.13.4-9.2.mga6 sssd-common-1.13.4-9.2.mga6 sssd-client-1.13.4-9.2.mga6 libsss_sudo-1.13.4-9.2.mga6 libsss_autofs-1.13.4-9.2.mga6 sssd-tools-1.13.4-9.2.mga6 python-sssdconfig-1.13.4-9.2.mga6 python3-sssdconfig-1.13.4-9.2.mga6 python-sss-1.13.4-9.2.mga6 python3-sss-1.13.4-9.2.mga6 python-sss-murmur-1.13.4-9.2.mga6 python3-sss-murmur-1.13.4-9.2.mga6 sssd-ldap-1.13.4-9.2.mga6 sssd-krb5-common-1.13.4-9.2.mga6 sssd-krb5-1.13.4-9.2.mga6 sssd-common-pac-1.13.4-9.2.mga6 sssd-ipa-1.13.4-9.2.mga6 sssd-ad-1.13.4-9.2.mga6 sssd-proxy-1.13.4-9.2.mga6 libsss_idmap-1.13.4-9.2.mga6 libsss_idmap-devel-1.13.4-9.2.mga6 libipa_hbac-1.13.4-9.2.mga6 libipa_hbac-devel-1.13.4-9.2.mga6 python-libipa_hbac-1.13.4-9.2.mga6 python3-libipa_hbac-1.13.4-9.2.mga6 libsss_nss_idmap-1.13.4-9.2.mga6 libsss_nss_idmap-devel-1.13.4-9.2.mga6 python-libsss_nss_idmap-1.13.4-9.2.mga6 python3-libsss_nss_idmap-1.13.4-9.2.mga6 sssd-dbus-1.13.4-9.2.mga6 libsss_simpleifp-1.13.4-9.2.mga6 libsss_simpleifp-devel-1.13.4-9.2.mga6 sssd-libwbclient-1.13.4-9.2.mga6 sssd-libwbclient-devel-1.13.4-9.2.mga6 from sssd-1.13.4-9.2.mga6.src.rpm
Whiteboard: MGA6TOO => (none)Version: Cauldron => 6Assignee: pkg-bugs => qa-bugs
Mageia 6, x86_64 Looks like I tried sssd in 2017 but got nowhere with it. Tried it again before trying to update anything. Installed all packages and enabled sssd.service then started it. It failed with an instruction to examine the journal. $ sudo journalctl -xe | grep sssd -- Subject: Unit sssd.service has begun start-up -- Unit sssd.service has begun starting up. Aug 14 18:32:26 difda sssd[31754]: NSCD socket was detected and seems to be configured to cache some of the databases controlled by SSSD [passwd,group,netgroup,services]. It is recommended not to run NSCD in parallel with SSSD, unless NSCD is configured not to cache these. Aug 14 18:32:26 difda sssd[31754]: Configuration file: /etc/sssd/sssd.conf does not exist. Aug 14 18:32:26 difda systemd[1]: sssd.service: Control process exited, code=exited status=4 -- Subject: Unit sssd.service has failed # systemctl stop nscd.service Warning: Stopping nscd.service, but it can still be activated by: nscd.socket # systemctl disable nscd Removed /etc/systemd/system/sockets.target.wants/nscd.socket. Removed /etc/systemd/system/multi-user.target.wants/nscd.service. That did not help, still no sssd.conf. Found an example at github with most of the entries commented out. Tried enabling some of the lines without having any clue as to what was required and ran the start command again. It failed, as expected. -- Subject: Unit sssd.service has begun start-up -- Unit sssd.service has begun starting up. Aug 14 18:55:30 difda sssd[2125]: Cannot read config file /etc/sssd/sssd.conf. Please check that the file is accessible only by the owner and owned by root.root. Aug 14 18:55:30 difda systemd[1]: sssd.service: Control process exited, code=exited status=4 # ll /etc/sssd/sssd.conf -rw-r--r-- 1 root root 1894 Aug 14 18:55 sssd.conf My example config file: [sssd] config_file_version = 2 services = nss, pam # SSSD will not start if you do not configure any domains. # Add new domain configurations as [domain/<NAME>] sections, and # then add the list of domains (in the order you want them to be # queried) to the "domains" attribute below and uncomment it. domains = LDAP [nss] [pam] # Example LDAP domain [domain/LDAP] id_provider = ldap auth_provider = ldap # ldap_schema can be set to "rfc2307", which stores group member names in the # "memberuid" attribute, or to "rfc2307bis", which stores group member DNs in # the "member" attribute. If you do not know this value, ask your LDAP # administrator. ldap_schema = rfc2307 ldap_uri = ldap://ldap.mydomain.org ldap_search_base = dc=mydomain,dc=org # Note that enabling enumeration will have a moderate performance impact. # Consequently, the default value for enumeration is FALSE. # Refer to the sssd.conf man page for full details. ; enumerate = false # Allow offline logins by locally storing password hashes (default: false). ; cache_credentials = true I suspect that I am too far out of my depth here - probably have to drop it.
CC: (none) => tarazed25
MGA6-32 MATE on IBM Thinkpad R50e No installation issues at first sight, but # systemctl -l status sssd ● sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled) Active: inactive (dead) That is OK # 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. # journalctl -xe | grep sss -- Subject: Unit sssd.service has begun start-up -- Unit sssd.service has begun starting up. aug 18 11:22:55 mach6.hviaene.thuis sssd[11824]: Configuration file: /etc/sssd/sssd.conf does not exist. # rpm -qf /etc/sssd sssd-common-1.13.4-9.2.mga6 Checked in MCC on the sssd-common package, this lists /etc/sssd /etc/sssd/sssd.conf Checked in file system: the folder /etc/sssd is created, but is empty. Something strikes me as strange : many daemon have the /etc conf files in the daemon package itself, not so here. But that cannot be a reason why the conf file is missing after installation???
CC: (none) => herman.viaene
You have to create the config file with the appropriate settings for your environment.
Yeah - figured that out in the end but it does not help without some experience of the subject. It does not help if you have no idea what the local settings should be. What does domain mean for instance? Or ldap_search_base? The suggestion that you ask your LDAP administrator is laughable. The man page for sssd.conf is completely opaque. "A domain is a database containing user information" so presumably that has to be created somehow. So it is simply not doable without a six-month induction course.
A domain is Active Directory or an LDAP domain. So you have to have a server set up to use one of those. I think you can also set up sssd to basically be a cache of the local users database.
Found example of conf file at https://gist.github.com/lashtear/e39ca0c5ac2ade6cc5b024d7780d842f Brought it (guessing) to a minimum as: [sssd] domains = local services = pam config_file_version = 2 #debug_level = 6 [pam] #debug_level = 6 [domain/local] id_provider = local auth_provider = local chpass_provider = local #debug_level = 6 After making sure the permissions are correct: ls -als /etc/sssd/sssd.conf 4 -rw------- 1 root root 202 aug 21 14:54 /etc/sssd/sssd.conf I could finally # systemctl start sssd # systemctl -l status sssd ● sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled) Active: active (running) since di 2018-08-21 14:56:04 CEST; 6s ago Process: 5260 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=0/SUCCESS) Main PID: 5265 (sssd) CGroup: /system.slice/sssd.service ├─5265 /usr/sbin/sssd -D -f └─5266 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files aug 21 14:56:03 mach6.xxx.yyy systemd[1]: Starting System Security Services Daemon... aug 21 14:56:03 mach6.xxx.yyy sssd[5265]: Starting up aug 21 14:56:04 mach6.xxx.yyy sssd[pam][5266]: Starting up aug 21 14:56:04 mach6.xxx.yyy systemd[1]: Started System Security Services Daemon. Looking up things in bug21917 I tried: # sss_useradd prutser [root@mach6 ~]# sss_groupshow prutser Magic Private Groep: prutser GID nummer: 1000 Lid gebruikers: Is lid van: Lid groepen: Seems to work after all, and thatś how far my knowledge goes. Note: if you want to know what "prutser" means, google translator helps.
Whiteboard: (none) => MGA6-32-OK
A good guess too Herman. Modified the config file along your lines and it worked. No idea what it all means. Re prutser: Aren't we all? translate-shell helps also - $ trans nl:en prutser ............ # systemctl start sssd [root@difda etc]# systemctl status sssd ● sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: Active: active (running) since Tue 2018-08-21 16:00:10 BST; 9s ago It looks like this is old ground. Thanks for the 21917 reference Herman. We seem to have done a lot of work that time but who has three days to spare any more? # sss_useradd frodo # sss_groupshow frodo Magic Private Group: frodo GID number: 1002 Member users: Is a member of: Member groups: Leaving it there - not satisfactory perhaps, but there it is. OK for 64-bits.
Whiteboard: MGA6-32-OK => MGA6-32-OK MGA6-64-OK
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Keywords: (none) => advisoryCC: (none) => tmb
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0350.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED