Fedora has issued an advisory on October 21: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/ZRITDM7DHTIP22EMB6BLSWDNQORASMCE/ Mageia 6 is also affected. Mageia 5 is not affected. The RedHat bug has a link to the upstream commit to fix the issue: https://bugzilla.redhat.com/show_bug.cgi?id=1498173 However, it does not apply to 1.13.x and a fix hasn't been committed to that branch yet: https://pagure.io/SSSD/sssd/commits/sssd-1-13
Whiteboard: (none) => MGA6TOO
openSUSE has issued an advisory for this today (November 7): https://lists.opensuse.org/opensuse-updates/2017-11/msg00016.html They patched SSSD 1.13.x, so we should be able to borrow their patch.
Patched packages uploaded for Mageia 6 and Cauldron. Advisory: ======================== Updated sssd packages fix security vulnerability: SSSD stores its cached data in an LDAP like local database file using libldb. To lookup cached data LDAP search filters like '(objectClass=user) (name=user_name)' are used. However, in sysdb_search_user_by_upn_res(), the input is not sanitized and allows to manipulate the search filter for cache lookups. This would allow a logged in user to discover the password hash of a different user (CVE-2017-12173). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12173 https://lists.opensuse.org/opensuse-updates/2017-11/msg00016.html ======================== Updated packages in core/updates_testing: ======================== sssd-1.13.4-9.1.mga6 sssd-common-1.13.4-9.1.mga6 sssd-client-1.13.4-9.1.mga6 libsss_sudo-1.13.4-9.1.mga6 libsss_autofs-1.13.4-9.1.mga6 sssd-tools-1.13.4-9.1.mga6 python-sssdconfig-1.13.4-9.1.mga6 python3-sssdconfig-1.13.4-9.1.mga6 python-sss-1.13.4-9.1.mga6 python3-sss-1.13.4-9.1.mga6 python-sss-murmur-1.13.4-9.1.mga6 python3-sss-murmur-1.13.4-9.1.mga6 sssd-ldap-1.13.4-9.1.mga6 sssd-krb5-common-1.13.4-9.1.mga6 sssd-krb5-1.13.4-9.1.mga6 sssd-common-pac-1.13.4-9.1.mga6 sssd-ipa-1.13.4-9.1.mga6 sssd-ad-1.13.4-9.1.mga6 sssd-proxy-1.13.4-9.1.mga6 libsss_idmap-1.13.4-9.1.mga6 libsss_idmap-devel-1.13.4-9.1.mga6 libipa_hbac-1.13.4-9.1.mga6 libipa_hbac-devel-1.13.4-9.1.mga6 python-libipa_hbac-1.13.4-9.1.mga6 python3-libipa_hbac-1.13.4-9.1.mga6 libsss_nss_idmap-1.13.4-9.1.mga6 libsss_nss_idmap-devel-1.13.4-9.1.mga6 python-libsss_nss_idmap-1.13.4-9.1.mga6 python3-libsss_nss_idmap-1.13.4-9.1.mga6 sssd-dbus-1.13.4-9.1.mga6 libsss_simpleifp-1.13.4-9.1.mga6 libsss_simpleifp-devel-1.13.4-9.1.mga6 sssd-libwbclient-1.13.4-9.1.mga6 sssd-libwbclient-devel-1.13.4-9.1.mga6 from sssd-1.13.4-9.1.mga6.src.rpm
Assignee: luigiwalser => qa-bugsWhiteboard: MGA6TOO => (none)Version: Cauldron => 6
Mageia 6 on x86_64 sssd ~=~ system services security daemon. $ urpmq --whatrequires sssd sssd sssd-tools $ urpmq -i sssd-tools Name : sssd-tools Version : 1.13.4 Release : 9.mga6 Group : System/Libraries Size : 833595 Architecture: x86_64 Source RPM : sssd-1.13.4-9.mga6.src.rpm URL : http://fedorahosted.org/sssd/ Summary : Userspace tools for use with the SSSD Description : Provides userspace tools for manipulating users, groups, and nested groups in SSSD when using id_provider = local in /etc/sssd/sssd.conf. Also provides several other administrative tools: * sss_debuglevel to change the debug level on the fly * sss_seed which pre-creates a user entry for use in kickstarts * sss_obfuscate for generating an obfuscated LDAP password Installed all the packages and then ran the updates. No problems there, but it is not obvious how these can be tested. There are a number of tools: $ ls /bin/sss* /bin/sss_ssh_authorizedkeys* /bin/sss_ssh_knownhostsproxy* # ls /sbin/*sss* /sbin/sss_cache* /sbin/sss_groupmod* /sbin/sss_useradd* /sbin/sssd* /sbin/sss_groupshow* /sbin/sss_userdel* /sbin/sss_debuglevel* /sbin/sss_obfuscate* /sbin/sss_usermod* /sbin/sss_groupadd* /sbin/sss_override* /sbin/sss_groupdel* /sbin/sss_seed* Tried to enable and start sssd but that fails and neither systemctl nor journalctl has any definite answers. There does not seem to be any config files in /etc/sssd. The probability is that they are generated on a first time run of something, but what? The failure may be due to the missing config file(s). /usr/share/sssd has various config files but I have no idea how they might be related to this problem. # sss_obfuscate --help Usage: sss_obfuscate [options] sss_obfuscate converts a given password into human-unreadable format and places it into appropriate domain section of the SSSD config file. The password can be passed in by stdin, specified on the command-line or entered interactively That seems doomed to failure given the lack of a config file. # sss_obfuscate -d localhost Enter password: Re-enter password: Permissions error reading config file # sss_cache Usage: sss_cache [-?EUGNSAH] [-?|--help] [--usage] [-E|--everything] [-u|--user=STRING] [-U|--users] [-g|--group=STRING] [-G|--groups] [-n|--netgroup=STRING] [-N|--netgroups] [-s|--service=STRING] [-S|--services] [-a|--autofs-map=STRING] [-A|--autofs-maps] [-h|--ssh-host=STRING] [-H|--ssh-hosts] [-d|--domain=STRING] Please select at least one object to invalidate # sss_useradd lcl (Wed Nov 15 19:44:55:199390 2017) [sss_useradd] [confdb_get_domains] (0x0010): No domains configured, fatal error! Error initializing the tools - no local domain # sss_seed -D=localhost.localdomain -n=lcl -u=1000 -h=/home/lcl -s=Bash (Wed Nov 15 19:48:56:186545 2017) [sss_seed] [confdb_get_domains] (0x0010): No domains configured, fatal error! Could not initialize connection to domain 'localhost.localdomain' in sysdb. Domain not found. Obviously, something has to be run to initialize the system but I have no clue. Does anybody here have any knowledge of LDAP and this sssd stuff? If not the update will have to be passed on the basis of a clean installation.
CC: (none) => tarazed25
As a rider to comment 3 there is an introduction at https://docs-old.fedoraproject.org/en-US/Fedora/16/html/System_Administrators_Guide/chap-SSSD_User_Guide-Introduction.html but I got lost on the second line.
You have to create /etc/sssd/sssd.conf. There's lots of examples out there. Some distros have tools to generate it (usually slightly incorrectly and then you have to adapt it), but we don't. Fedora has realmd, which we used to have, but nobody ever adapted it for Mageia. I talked with Thierry once about having drakuser do it, but it was easier with the existing code to have it configure nss-pam-ldapd instead.
Thanks David - shall follow up on that.
No further forward on this. None of the examples are working examples because they all need editing to fit in with the user's local system and that requires a deeper knowledge of the terms used. From a starting point of 0 knowledge this is going to takes weeks of study of fields which I have no interest in so it looks like a no-go. The complexity of this thing now makes sense of the absence of a "standard" config file; there can be no such thing.
There is no standard, it's particular to your environment and what you're trying to authenticate against. You can actually configure it to authenticate against the local password database if I'm not mistaken, so that would be the simplest test.
Re comment 8. "There is no standard, it's particular to your environment..." That was my point : "There can be no such thing". Again, what you suggest is completely beyond me. Would have no idea where to start. I do not know or understand half the terms that appear in the documentation. This has to be left for somebody who is familiar with the landscape.
Len, try using this as your /etc/sssd/sssd.conf. It will just use your local passwd database. Then start the sssd service and put sss in the passwd, shadow, and group lines in /etc/nsswitch.conf. Then, the commands "getent passwd" and "getent group" should still work. [sssd] config_file_version = 2 services = nss, pam domains = local [nss] filter_groups = root filter_users = root [pam] [domain/local] id_provider = local enumerate = true
Thanks for helping out David. Copied the config file verbatim to /etc/sssd.conf (644) and tried to start the service. That did not go too well. Nov 16 21:12:14 belexeuli sssd[25846]: NSCD socket was detected and seems to be configured to cache some of the databases controlled Nov 16 21:12:14 belexeuli sssd[25846]: Cannot read config file /etc/sssd/sssd.conf. Please check that the file is accessible only by Nov 16 21:12:14 belexeuli systemd[1]: sssd.service: Control process exited, code=exited status=4 Nov 16 21:12:14 belexeuli systemd[1]: Failed to start System Security Services Daemon. Nor can I log in to su or any user any more. Luckily I still have a terminal with root running. nsswitch had been edited for sss control. I need to revert that and find out how ownership can be changed to sss or sssd. sss and sssd are not recognized as users so there must be some other way to confine the file to sssd.service. Found it. It just needs to be root only => 600. sssd now starts. Modified nsswitch.conf and su fails again. Also need to research "getent".
sudo works though.
$ getent passwd lcl lcl:x:1000:1000:Len Lawrence:/home/lcl:/bin/bash $ getent group lcl lcl:x:1000:mysql
$ journalctl -xe Nov 16 20:53:02 belexeuli su[18639]: (to root) lcl on pts/5 Nov 16 20:53:02 belexeuli su[18639]: pam_systemd(su:session): Cannot create session: Alrea Nov 16 20:53:02 belexeuli su[18639]: pam_unix(su:session): session opened for user root by Nov 16 21:05:06 belexeuli su[23210]: FAILED SU (to root) lcl on pts/4 Nov 16 21:21:33 belexeuli su[29036]: FAILED SU (to root) lcl on pts/7 Nov 16 21:22:56 belexeuli su[29540]: FAILED SU (to lcl) lcl on pts/7 Nov 16 21:29:14 belexeuli su[31740]: (to lcl) lcl on pts/0 Nov 16 21:29:14 belexeuli su[31740]: pam_systemd(su:session): Cannot create session: Alrea Nov 16 21:29:14 belexeuli su[31740]: pam_unix(su:session): session opened for user lcl by Nov 16 21:39:23 belexeuli su[2632]: (to root) lcl on pts/2 Nov 16 21:39:23 belexeuli su[2632]: pam_systemd(su:session): Cannot create session: Alread Nov 16 21:39:23 belexeuli su[2632]: pam_unix(su:session): session opened for user root by Nov 16 21:48:59 belexeuli su[5235]: FAILED SU (to root) lcl on pts/1 Nov 16 21:51:38 belexeuli su[5953]: FAILED SU (to lcl) lcl on pts/7 Nov 16 21:53:40 belexeuli pkexec[6543]: lcl: Error executing command as another user: Requ Nov 16 21:55:21 belexeuli pkexec[6976]: lcl: Error executing command as another user: Requ Nov 16 22:05:22 belexeuli su[9357]: FAILED SU (to root) lcl on pts/7
# sss_obfuscate -d local Enter password: Re-enter password: The domain local does not seem to support the required options
This is nsswitch.conf: passwd: sss shadow: sss group: sss hosts: mdns4_minimal files nis dns mdns4 belexeuli networks: files services: files protocols: files rpc: files ethers: files netmasks: files netgroup: files publickey: files bootparams: files automount: files aliases: files Have to revert it again.
If sss is replaced by 'sss files' in the nsswitch.conf file then su works again, but that is a bit of a copout in the context of this test. sssd cannot find either a service to access the password files or does not know itself where they are, whichever way it works. So some connection is missing somewhere. The documentation says that the debug_level=n specification can be used anywhere but it seems to cripple sssd. Offending line in sssd.conf is: id_provider = local,debug_level=3 Also noticed recurring messages in the journal: Nov 16 23:59:02 belexeuli postfix/bounce[27171]: warning: [built-in]: conversion "myhostname" failed: input value: "belexeuli.locald Nov 16 23:59:02 belexeuli postfix/cleanup[22501]: 1D5444C2C28: message-id=<20171116235902.1D5444C2C28@belexeuli.localdomain> Nov 16 23:59:02 belexeuli postfix/bounce[27171]: 008EA4C2C27: sender non-delivery notification: 1D5444C2C28 Nov 16 23:59:02 belexeuli postfix/qmgr[7178]: 1D5444C2C28: from=<>, size=2908, nrcpt=1 (queue active) Nov 16 23:59:02 belexeuli postfix/qmgr[7178]: 008EA4C2C27: removed Nov 16 23:59:02 belexeuli postfix/local[22506]: 1D5444C2C28: to=<apache@belexeuli.localdomain>, relay=local, delay=0.13, delays=0.04 Nov 16 23:59:02 belexeuli postfix/qmgr[7178]: 1D5444C2C28: removed Returning to debug. Not a problem if it is supplied on a line by itself. Placed it under [pam] and sssd restarted. Don't know where the errors are logged - don't see them in the journal.
/var/log/sssd Extracts: # cat sssd_pam.log (Fri Nov 17 00:14:44 2017) [sssd[pam]] [monitor_common_send_id] (0x0100): Sending ID: (pam,1) (Fri Nov 17 00:14:44 2017) [sssd[pam]] [sss_names_init_from_args] (0x0100): Using re [(?P<name>[^@]+)@?(?P<domain>[^@]*$)]. (Fri Nov 17 00:14:44 2017) [sssd[pam]] [sss_fqnames_init] (0x0100): Using fq format [%1$s@%2$s]. (Fri Nov 17 00:14:44 2017) [sssd[pam]] [sysdb_domain_init_internal] (0x0200): DB File for local: /var/lib/sss/db/sssd.ldb (Fri Nov 17 00:14:44 2017) [sssd[pam]] [ldb] (0x0400): asq: Unable to register control with rootdse! (Fri Nov 17 00:14:44 2017) [sssd[pam]] [sss_process_init] (0x0400): Responder Initialization complete (Fri Nov 17 00:14:44 2017) [sssd[pam]] [get_trusted_uids] (0x0400): All UIDs are allowed. (Fri Nov 17 00:14:44 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'root' matched without domain, user is root (Fri Nov 17 00:14:44 2017) [sssd[pam]] [sss_ncache_set_str] (0x0400): Adding [NCE/USER/local/root] to negative cache permanently (Thu Nov 16 23:55:53 2017) [sssd[be[local]]] [be_process_init] (0x0010): fatal error initializing data providers (Thu Nov 16 23:55:53 2017) [sssd[be[local]]] [main] (0x0010): Could not initialize backend [79] (Thu Nov 16 23:55:57 2017) [sssd[be[local]]] [load_backend_module] (0x0010): Unable to load local,debug_level=3 module with path (/usr/lib64/sssd/libsss_local,debug_level=3.so), error: /usr/lib64/sssd/libsss_local,debug_level=3.so: cannot open shared object file: No such file or directory (Thu Nov 16 23:55:57 2017) [sssd[be[local]]] [be_process_init] (0x0010): fatal error initializing data providers (Thu Nov 16 23:55:57 2017) [sssd[be[local]]] [main] (0x0010): Could not initialize backend [79] # cat sssd_nss.log (Thu Nov 16 23:55:56 2017) [sssd[nss]] [sss_dp_init] (0x0010): Failed to connect to monitor services. (Thu Nov 16 23:55:56 2017) [sssd[nss]] [sss_process_init] (0x0010): fatal error setting up backend connector (Thu Nov 16 23:55:56 2017) [sssd[nss]] [nss_process_init] (0x0010): sss_process_init() failed
Sigh! Losing the will to live here. Need sleep.....
Resumé.... 1) Edited /etc/sssd/sssd.conf: Inserted 'debug_level = 7' under [nss], [pam] and [domain/local] 2) Removed existing log files from /var/log/sssd/ 3) Edited /etc/nsswitch.conf Replaced 'files' by 'sss' for passwd, shadow and group. 4) # systemctl restart sssd 5) # ls -l /var/log/sssd total 8 -rw------- 1 root root 0 Nov 17 09:20 sssd.log -rw------- 1 root root 3763 Nov 17 09:20 sssd_nss.log -rw------- 1 root root 2943 Nov 17 09:20 sssd_pam.log 6) $ su zack Password: su: Authentication failure $ su lcl Password: su: Authentication failure 7) # ls -l /var/log/sssd/ total 8 -rw------- 1 root root 0 Nov 17 09:20 sssd.log -rw------- 1 root root 3763 Nov 17 09:20 sssd_nss.log -rw------- 1 root root 2943 Nov 17 09:20 sssd_pam.log Nothing written to the logs.
Increasing the debug level to the maximum, 9, did not help much. The logs start to grow but there is nothing that helps. Both pam and nss add messages after 'su zack', which fails. Tail of either pam or nss logs looks like this: (Fri Nov 17 10:29:08 2017) [sssd[nss]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Fri Nov 17 10:29:18 2017) [sssd[nss]] [sbus_dispatch] (0x4000): dbus conn: 0x22e1b80 (Fri Nov 17 10:29:18 2017) [sssd[nss]] [sbus_dispatch] (0x4000): Dispatching. (Fri Nov 17 10:29:18 2017) [sssd[nss]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Fri Nov 17 10:29:18 2017) [sssd[nss]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Fri Nov 17 10:29:28 2017) [sssd[nss]] [sbus_dispatch] (0x4000): dbus conn: 0x22e1b80 (Fri Nov 17 10:29:28 2017) [sssd[nss]] [sbus_dispatch] (0x4000): Dispatching. (Fri Nov 17 10:29:28 2017) [sssd[nss]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Fri Nov 17 10:29:28 2017) [sssd[nss]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit Means nothing to me.
Editing nsswitch.conf to contain: passwd: sss files shadow: sss files group: sss files results in a successful 'su zack' but the sysbus failures are still written to the logs, no sign of a successful authorization, which implies that the process falls through sss to the files service, so we are no further forward. sssd.log ends on this note: (Fri Nov 17 11:23:14 2017) [sssd] [ping_check] (0x2000): Service pam replied to ping (Fri Nov 17 11:23:14 2017) [sssd] [sbus_remove_timeout] (0x2000): 0x1486d70 (Fri Nov 17 11:23:14 2017) [sssd] [sbus_dispatch] (0x4000): dbus conn: 0x1482eb0 (Fri Nov 17 11:23:14 2017) [sssd] [sbus_dispatch] (0x4000): Dispatching. (Fri Nov 17 11:23:14 2017) [sssd] [ping_check] (0x2000): Service nss replied to ping Disabling sssd. Unless anyone else has ideas how to proceed at this point I am going to drop this update altogether. Two days on one update is ridiculous.
Configuring NSS (/etc/nsswitch.conf) only allows you to look up account information (that's what getent does). I didn't know you were going to try to authenticate with it as well. That requires configuring PAM (/etc/pam.d/system-auth). In system-auth, add this line after the pam_tcb.so line in the auth section: auth sufficient pam_sss.so In the account section, change pam_deny to pam_permit and add this line after the pam_tcb.so one: account [default=bad success=ok user_unknown=ignore] pam_sss.so In the password section, add this after the pam_tcb.so line: password sufficient pam_sss.so use_authtok and finally in the session section, add this after the pam_tcb.so line: session optional pam_sss.so
Thanks again David for doing my job for me and you are quite right, I don't know what I am doing. Having some difficulties with your suggestions though: # locate pam_tcb.so /usr/lib64/security/pam_tcb.so # updatedb # locate pam_sss.o # Cannot find the pam_sss module and system-auth does not reference pam_tcb. There are lots of hits on pam_sss using Google but no clear indication of where it comes from. -------------------------------------------------------------------------------- #%PAM-1.0 auth required pam_env.so auth sufficient pam_unix.so try_first_pass likeauth nullok auth required pam_deny.so account required pam_unix.so password required pam_cracklib.so try_first_pass retry=3 minlen=4 dcredit=0 ucredit=0 password sufficient pam_unix.so try_first_pass use_authtok nullok sha512 shadow password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid -session optional pam_systemd.so session required pam_unix.so -------------------------------------------------------------------------------- Different from your version. There may well be a whole raft of components missing from my system since I have never had anything to do with this security level stuff. A foreign country indeed.
Ok, where I said pam_tcb before, pam_unix serves the same purpose, so just put the pam_sss lines after those. The pam_sss.so file is in the same directory as the other ones, you just typoed it in your locate command.
Thanks again David. This is how it looks now; not sure if all instances of pam_deny should be changed but did so anyway. ----------------------------------------------------------------------------- auth required pam_env.so auth sufficient pam_sss.so auth sufficient pam_unix.so try_first_pass likeauth nullok auth sufficient pam_sss.so auth required pam_permit.so account required pam_unix.so account [default=bad success=ok user_unknown=ignore] pam_sss.so password required pam_cracklib.so try_first_pass retry=3 minlen=4 dcredit=0 ucredit=0 password sufficient pam_unix.so try_first_pass use_authtok nullok sha512 shadow password sufficient pam_sss.so use_authtok password required pam_permit.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid -session optional pam_systemd.so session required pam_unix.so session optional pam_sss.so ----------------------------------------------------------------------------- Also, I don't know how nsswitch fits in to all this. With 'sss files' authentication succeeded but with sss on its own it failed. There were three attempts at authentication for the one user and the tail of the journal showed: Nov 17 20:10:50 belexeuli su[11693]: pam_sss(su:auth): authentication failure; logname= uid=1000 euid=0 tty=pts/1 ruser=lcl rhost= u Nov 17 20:10:50 belexeuli su[11693]: pam_sss(su:auth): received for user zack: 10 (User not known to the underlying authentication m Nov 17 20:11:03 belexeuli su[11693]: pam_sss(su:auth): authentication failure; logname= uid=1000 euid=0 tty=pts/1 ruser=lcl rhost= u Nov 17 20:11:03 belexeuli su[11693]: pam_sss(su:auth): received for user zack: 10 (User not known to the underlying authentication m Nov 17 20:11:03 belexeuli su[11693]: pam_sss(su:account): Access denied for user zack: 10 (User not known to the underlying authenti Nov 17 20:11:03 belexeuli su[11693]: FAILED SU (to zack) lcl on pts/1 $ su zack Password: Password: Password: su: Authentication service cannot retrieve authentication info $ getent passwd zack zack:x:1001:1001::/home/zack:/bin/bash
Not sure how to proceed with this. Using sss in preference to files, getent queries succeed. With the modified pam configuration su athentication succeeds but user authentication does not. Could be a regression (seems unlikely) or pam misconfiguration, or something else.
I didn't expect the local thing to be so problematic. I've never tested it. I guess it's easier if you have an AD or LDAP server to test against. I gave setup instructions for AD at: https://bugs.mageia.org/show_bug.cgi?id=19103#c24 Setting up an LDAP server from scratch is a bit of work, but I based my setup on: https://annvix.com/Using_OpenLDAP_for_User_Authentication
Thanks again David for taking the time to mentor me. I am pursuing the LDAP route. It may take a while.
Researching M6/64 The main previous bug was https://bugs.mageia.org/show_bug.cgi?id=9027 which also went on & on, and nobody won. But it has useful indications. Of the various references given therein, only https://jhrozek.fedorapeople.org/sssd/1.8.5/man/ (shows the various sss commands) seems pertinant for us. I shall install everything, try to get something to work, then see how it updates.
CC: (none) => lewyssmith
M6/64 cont. Start point BEFORE update. From issued repos: libipa_hbac-1.13.4-9.mga6 libsss_autofs-1.13.4-9.mga6 libsss_idmap-1.13.4-9.mga6 libsss_nss_idmap-1.13.4-9.mga6 libsss_simpleifp-1.13.4-9.mga6 libsss_sudo-1.13.4-9.mga6 python3-libsss_nss_idmap-1.13.4-9.mga6 python3-sss-1.13.4-9.mga6 python3-sssdconfig-1.13.4-9.mga6 python3-sss-murmur-1.13.4-9.mga6 python-libsss_nss_idmap-1.13.4-9.mga6 python-sss-1.13.4-9.mga6 python-sssdconfig-1.13.4-9.mga6 python-sss-murmur-1.13.4-9.mga6 sssd-1.13.4-9.mga6 sssd-ad-1.13.4-9.mga6 sssd-client-1.13.4-9.mga6 sssd-common-1.13.4-9.mga6 sssd-common-pac-1.13.4-9.mga6 sssd-dbus-1.13.4-9.mga6 sssd-ipa-1.13.4-9.mga6 sssd-krb5-1.13.4-9.mga6 sssd-krb5-common-1.13.4-9.mga6 sssd-ldap-1.13.4-9.mga6 sssd-libwbclient-1.13.4-9.mga6 sssd-proxy-1.13.4-9.mga6 sssd-tools-1.13.4-9.mga6 /etc/sssd/ exists but is empty initially. Created it as per comment 10, set permissions 600. /var/lib/sss/ has several directories, of which 'db' is empty initially. /etc/nsswitch.conf included initially: passwd: files shadow: files group: files Unsure to start with whether 'sss' needs appending or substituting, since the sample lines give 'files nis'. Will try appending first. -------------------------------------------------------- # systemctl start sssd.service # systemctl status sssd.service ● sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: Active: active (running) since Llu 2017-11-20 09:58:24 CET; 3s ago ... Tach 20 09:58:22 localhost.localdomain systemd[1]: Starting System Security Serv Tach 20 09:58:23 localhost.localdomain sssd[698]: Starting up Tach 20 09:58:24 localhost.localdomain sssd[nss][699]: Starting up Tach 20 09:58:24 localhost.localdomain sssd[pam][700]: Starting up Tach 20 09:58:24 localhost.localdomain systemd[1]: Started System Security Servi # sss_groupadd -g 1010 sssd [Does not show in /etc/group] # ls -l /var/lib/sss/db -rw------- 1 root root 1286144 Tach 20 09:58 config.ldb -rw------- 1 root root 1286144 Tach 20 10:10 sssd.ldb Looks hopeful. # sss_groupdel sssd # sss_groupadd -g 1010 sssg # sss_useradd -u 1010 -m -G sssg sssu # ls -l /home drwx------ 4 sssu root 4096 Gor 12 08:47 sssu/ # passwd sssu Changing password for user sssu. passwd: Authentication token manipulation error which was a problem hit in the old bug. So I am accepting it as-is. # su sssu id: cannot find name for group ID 1010 [BUT see follows & below] $ id uid=1010(sssu) gid=1010 groups=1010 $ exit # # sss_groupshow sssg Group: sssg GID number: 1010 Member users: sssu Is a member of: Member groups: $ su sssu [from a normal user terminal] Password: [just Enter, since none defined] su: Authentication failure # sss_userdel -r sssu [removes /home/sssu/] # sss_groupdel sssg # sss_groupshow sssg No such group in local domain. # systemctl stop sssd.service [to do the update]
AFTER the update of all 27 installed pkgs to 1.13.4-9.1 # ls -l /var/lib/sss/db [still there] -rw------- 1 root root 1286144 Tach 20 09:58 config.ldb -rw------- 1 root root 1286144 Tach 20 10:52 sssd.ldb /etc/sssd/sssd.conf unchanged. # systemctl start sssd.service # systemctl status sssd.service [O/P as previously] # sss_groupadd -g 1010 sssg # sss_useradd -u 1010 -m -G sssg sssu # ls -l /home drwx------ 4 sssu root 4096 Gor 12 08:47 sssu/ # getent passwd [when *not* in group] sssu:*:1010:1010:sssu:/home/sssu:/bin/bash # passwd sssu [same failure as before] Changing password for user sssu. passwd: Authentication token manipulation error # sss_groupshow sssg [O/P as previously, all correct] # su sssu id: cannot find name for group ID 1010 $ id [all same as previously] uid=1010(sssu) gid=1010 groups=1010 $ exit # [From a normal terminal] $ su sssu [fails as previously] # sss_userdel -r sssu # sss_groupdel sssg # sss_groupshow sssg all as previously. Since the simple behaviour is the same over the update, I think it is OK. @ Len, after your superhuman efforts, if you beg to differ - feel free. But if you agree about the 64 OK, please validate the update. Advisory done.
Keywords: (none) => advisoryWhiteboard: (none) => MGA6-64-OK
Will do.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2017-0421.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED