libnss_compat is disabled by default: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=1e4d83f6fe38613e6f209ff09dfad8e69a6e1629 Should be restorable with --enable-obsolete-nsl Currently we hardcode 'compat' resolver in gentoo's nsswitch.conf: https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/glibc/extra/etc/nsswitch.conf?view=markup passwd: compat shadow: compat group: compat
I suggest adding files fallback to all glibc patchsets right now: cvs/gentoo/src/patchsets/glibc/extra/etc:cvs diff -U1 Index: nsswitch.conf =================================================================== RCS file: /var/cvsroot/gentoo/src/patchsets/glibc/extra/etc/nsswitch.conf,v retrieving revision 1.1 diff -u -U1 -r1.1 nsswitch.conf --- nsswitch.conf 29 Sep 2006 23:52:23 -0000 1.1 +++ nsswitch.conf 12 Aug 2017 08:22:39 -0000 @@ -3,9 +3,5 @@ -passwd: compat -shadow: compat -group: compat - -# passwd: db files nis -# shadow: db files nis -# group: db files nis +passwd: compat files +shadow: compat files +group: compat files
Updated in glibc's gentoo patchset as: https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/glibc/extra/etc/nsswitch.conf?view=diff&r1=text&tr1=1.2&r2=text&tr2=1.1&diff_format=h
Pushed to 2.24-r4 and 2.25-r3 as: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=280e225b50f7ab21e84d112087784c5424ba00be For users who did not modify /etc/nsswitch.conf portage will upgrade config by default (FEATURES=config-protect-if-modified). For user who have tweaked nsswitch.conf we will need to have a pkg_setup() safety check to prevent system from user/group resolution after upgrade.
This update breaks x11-misc/sddm: entries doubled Google showed redhat fighted a similar problem: ---- https://bugzilla.redhat.com/show_bug.cgi?id=1446782#c5 Palo Kisa 2017-06-09 03:46:39 EDT Source of this problem probably is the usage of getpwent() and configuration in /etc/nsswitch.conf -> see here https://github.com/lxde/lxqt/issues/1308#issuecomment-307309844 ----
Workaround for sddm: +passwd: files +shadow: files +group: files --- Though only I know sddm works again. I don't what other services might be affected loosing the 'compat' keyword.
(In reply to Ulenrich from comment #4) > This update breaks x11-misc/sddm: entries doubled For sddm is a upstream Patch available, see https://github.com/sddm/sddm/commit/1f39c7a91ea4bc9527628adb01cb49173f1e68be This Patch fixed the issue for current =x11-misc/sddm-0.14.0-r3
(In reply to Ulenrich from comment #4) > This update breaks x11-misc/sddm: entries doubled > Google showed redhat fighted a similar problem: > > ---- https://bugzilla.redhat.com/show_bug.cgi?id=1446782#c5 > Palo Kisa 2017-06-09 03:46:39 EDT > Source of this problem probably is the usage of getpwent() and configuration > in /etc/nsswitch.conf -> see here > https://github.com/lxde/lxqt/issues/1308#issuecomment-307309844 > ---- Can you file a sddm bug for gentoo bug tracker gentoo and clarify what "breaks" mean? Failure to login?
Created attachment 489104 [details, diff] nss-mdns-9999-src-nss.c-fix-out-of-bounds-memset.patch nss-mdns-9999-src-nss.c-fix-out-of-bounds-memset.patch should fix the OOB.
(In reply to Sergei Trofimovich from comment #8) > Created attachment 489104 [details, diff] [details, diff] > nss-mdns-9999-src-nss.c-fix-out-of-bounds-memset.patch > > nss-mdns-9999-src-nss.c-fix-out-of-bounds-memset.patch should fix the OOB. Please ignore, wrong bug.
(In reply to Sergei Trofimovich from comment #7) > (In reply to Ulenrich from comment #4) > > This update breaks x11-misc/sddm: entries doubled > > Google showed redhat fighted a similar problem: > > > > ---- https://bugzilla.redhat.com/show_bug.cgi?id=1446782#c5 > > Palo Kisa 2017-06-09 03:46:39 EDT > > Source of this problem probably is the usage of getpwent() and configuration > > in /etc/nsswitch.conf -> see here > > https://github.com/lxde/lxqt/issues/1308#issuecomment-307309844 > > ---- > > Can you file a sddm bug for gentoo bug tracker gentoo and clarify what > "breaks" mean? Failure to login? Issue with sddm regarding "compat files" has been fixed here: https://bugs.gentoo.org/show_bug.cgi?id=627902
Please note that with: passwd: compat files shadow: compat files group: compat files getent is now returning double entry: # getent passwd root root:x:0:0:root:/root:/bin/bash # getent passwd | grep ^root root:x:0:0:root:/root:/bin/bash root:x:0:0:root:/root:/bin/bash # getent group root root:x:0:root # getent group | grep ^root root:x:0:root root:x:0:root This may impact some application using getent
(In reply to Bertrand Jacquin from comment #11) > Please note that with: > > passwd: compat files > shadow: compat files > group: compat files > > getent is now returning double entry: > > # getent passwd root > root:x:0:0:root:/root:/bin/bash > # getent passwd | grep ^root > root:x:0:0:root:/root:/bin/bash > root:x:0:0:root:/root:/bin/bash > > # getent group root > root:x:0:root > # getent group | grep ^root > root:x:0:root > root:x:0:root > > This may impact some application using getent It definitely impacts sddm, which now lists all users twice on the login screen.
(In reply to Andreas K. Hüttel from comment #12) > (In reply to Bertrand Jacquin from comment #11) > > Please note that with: > > > > passwd: compat files > > shadow: compat files > > group: compat files > > > > getent is now returning double entry: > > > > # getent passwd root > > root:x:0:0:root:/root:/bin/bash > > # getent passwd | grep ^root > > root:x:0:0:root:/root:/bin/bash > > root:x:0:0:root:/root:/bin/bash > > > > # getent group root > > root:x:0:root > > # getent group | grep ^root > > root:x:0:root > > root:x:0:root > > > > This may impact some application using getent > > It definitely impacts sddm, which now lists all users twice on the login > screen. Add x11-misc/lightdm to that list.
cinnamon-settings-users part of cinnamon also
Can we consider just dropping compat completely? Looks like all other distros have pretty much dropped it too. SELinux recently added an mmap permission check and when compat is enabled every nss program does a map before falling back to a regular read(). "files" doesnt have that issue as it only does read(). its not vital but its pretty annoying that the logs fill up with the permission denials.
This is my $0.02 after running into this yesterday when 2.26 was unmasked: I don't think glibc-2.26 should have been unmasked before this was fixed. The first system I tested on has a modified nsswitch.conf to use ldap. The update nearly rendered the system unusable as no groups and no users meant no root. Luckily I caught and fixed it before I closed the root shell. It would be easy for any users with a modified nsswitch.conf to wind up in this situation and modified configs are probably not uncommon with things like mdns, ldap, ldap sudoers, etc. Personally, I think it should be masked again and shouldn't be unmasked until one or both of the following: 1. Continue to support compat by default. 2. Rev bumps to update the default nsswitch.conf to use files. Give users sufficient time to update before unmasking 2.26. A news item before the package goes stable telling users to move away from compat would be good in either case.
(In reply to Daniel M. Weeks from comment #16) I agree we should do something about it to make transition path smoother or at least less fragile. We need to figure out a way to check that existing user's config is broken WRT newly installed libc. I'm afraid there is no easy way to do it before the fact. Perhaps bailing out in 'pkg_setup()/pkg_pretend()' on check like egrep 'passwd:.*files' /etc/nsswitch.conf and pointing to a wiki page with instructions on how to unbreak the system would help. Writing a news item is certainly worthwile.
Added wiki page for everyone to add details: https://wiki.gentoo.org/wiki/Project:Toolchain/nsswitch.conf_in_glibc-2.26
(In reply to Sergei Trofimovich from comment #17) > Perhaps bailing out in 'pkg_setup()/pkg_pretend()' on check like > egrep 'passwd:.*files' /etc/nsswitch.conf > and pointing to a wiki page with instructions on how to > unbreak the system would help. Grepping for "compat" would make more sense. There's only a problem if someone uses "compat files" (or "files compat"), and in the longer term, we want everyone to get rid of "compat", not "files". Also, why does the wiki page you created call the configuration "passwd: compat files" "also good", when we know it can cause problems for DMs and potentially other applications?
I just got bitten by this issue. I updated my system and suddenly it could not find uid 0. I didn't see an elog message. Or maybe it tried to send one but my elog is set up to send emails and after glibc was upgraded the system was no longer able to call sendmail. Unfortunately I do not have a root shell open as I call emerge via `sudo` and sudo no longer works. I'll try booting with a boot cd and changing `compat` to `files` in `/etc/nsswitch.conf`. I have a modified `nsswitch.conf` so if portage tried to modify it on it's own perhaps it failed.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66b10cf352d69a96824cba2c2a2bdea8e8094d7b commit 66b10cf352d69a96824cba2c2a2bdea8e8094d7b Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2017-11-13 23:23:10 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2017-11-13 23:25:59 +0000 sys-libs/glibc: guard against rendering system unusable, bug #627338 For cases like FEATURES=config-protect-if-modified or custom /etc/nsswitch.conf with only 'compat' resolver and external providers glibc upgrade will break local user resolution when switching from older glibc. Bad /etc/nsswitch.conf: passwd: compat shadow: compat group: compat Good /etc/nsswitch.conf: passwd: files shadow: files group: files Ok /etc/nsswitch.conf: passwd: compat files shadow: compat files group: compat files More up-to-date doc: https://wiki.gentoo.org/wiki/Project:Toolchain/nsswitch.conf_in_glibc-2.26 Bug: https://bugs.gentoo.org/627338 Package-Manager: Portage-2.3.13, Repoman-2.3.4 sys-libs/glibc/glibc-2.26-r3.ebuild | 15 +++++++++++++++ 1 file changed, 15 insertions(+)}
(In reply to Luis Ressel from comment #19) > (In reply to Sergei Trofimovich from comment #17) > > > Perhaps bailing out in 'pkg_setup()/pkg_pretend()' on check like > > egrep 'passwd:.*files' /etc/nsswitch.conf > > and pointing to a wiki page with instructions on how to > > unbreak the system would help. > > > Grepping for "compat" would make more sense. There's only a problem if > someone uses "compat files" (or "files compat"), and in the longer term, we > want everyone to get rid of "compat", not "files". glibc-2.25 and glibc-2.26 currently creates nsswitch.conf with the following entries: https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/glibc/extra/etc/nsswitch.conf?view=markup passwd: compat files shadow: compat files group: compat files wiki page reflects the real state user gets by default for a working system. It would be confusing to try to get rid of 'compat' and keep being suggested from etc-update to switch back to 'compat on every glibc update. We need to fix that first. > Also, why does the wiki page you created call the configuration "passwd: > compat files" "also good", when we know it can cause problems for DMs and > potentially other applications? AFAIU 'compat files' does not cause any real problems like lost functionality. It only causes inconvenience on glibc-2.25 while still preserving system in a working state in glibc-2.25 -> 2.26 transition and keeps working for whatever difference nss_compat compared to nss_files. But yes, it makes sense to get rid of 'compat' in glibc-2.26 completely. The question is: Would we have to roll glibc back to --enable-obsolete-nsl in a last minute if something is badly relying on compat module and there is no easy workaround for that?
(In reply to Larry the Git Cow from comment #21) > The bug has been referenced in the following commit(s): > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=66b10cf352d69a96824cba2c2a2bdea8e8094d7b > > commit 66b10cf352d69a96824cba2c2a2bdea8e8094d7b > Author: Sergei Trofimovich <slyfox@gentoo.org> > AuthorDate: 2017-11-13 23:23:10 +0000 > Commit: Sergei Trofimovich <slyfox@gentoo.org> > CommitDate: 2017-11-13 23:25:59 +0000 > > [...] > > sys-libs/glibc/glibc-2.26-r3.ebuild | 15 +++++++++++++++ > 1 file changed, 15 insertions(+)} I believe this check to be insufficient, since the regexp will also trigger on: #passwd: compat files
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5d8d827255a5f831247dc838879c4582b46210c4 commit 5d8d827255a5f831247dc838879c4582b46210c4 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2017-11-14 09:35:48 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2017-11-14 09:35:48 +0000 sys-libs/glibc: added missing anchor to nsswitch.conf check, bug #627338 Original change meant to ignore lines starting with comment but was missing leading like anchor. Added. Reported-by: Dennis Schridde Bug: https://bugs.gentoo.org/627338 Package-Manager: Portage-2.3.13, Repoman-2.3.4 sys-libs/glibc/glibc-2.26-r3.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)}
(In reply to Dennis Schridde from comment #23) > (In reply to Larry the Git Cow from comment #21) > > The bug has been referenced in the following commit(s): > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > > ?id=66b10cf352d69a96824cba2c2a2bdea8e8094d7b > > > > commit 66b10cf352d69a96824cba2c2a2bdea8e8094d7b > > Author: Sergei Trofimovich <slyfox@gentoo.org> > > AuthorDate: 2017-11-13 23:23:10 +0000 > > Commit: Sergei Trofimovich <slyfox@gentoo.org> > > CommitDate: 2017-11-13 23:25:59 +0000 > > > > [...] > > > > sys-libs/glibc/glibc-2.26-r3.ebuild | 15 +++++++++++++++ > > 1 file changed, 15 insertions(+)} > > I believe this check to be insufficient, since the regexp will also trigger > on: > #passwd: compat files Good catch! Tweaked.
If the compat module will be gone what actually replaces it? The files module does not offer the same functionality. Using something like 'compat files nis' makes for some interesting results, where any +/- lines in the databases will show up in getent (in addition to the duplicate entries).
(In reply to Nick Bowler from comment #26) > If the compat module will be gone what actually replaces it? > > The files module does not offer the same functionality. > > Using something like 'compat files nis' makes for some interesting results, > where any +/- lines in the databases will show up in getent (in addition to > the duplicate entries). Does anyone have an answer to this question? I rely on the behavior provided by nss_compat.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b1c1e8e9061dacd956220e2078fc0a933e7f3040 commit b1c1e8e9061dacd956220e2078fc0a933e7f3040 Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2018-04-21 21:50:39 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2018-04-21 21:51:15 +0000 sys-auth/libnss-compat: Add separate libnss_compat module, bug 627338 Only for people who really, really, really need it... Bug: https://bugs.gentoo.org/627338 Package-Manager: Portage-2.3.27, Repoman-2.3.9 sys-auth/libnss-compat/Manifest | 1 + sys-auth/libnss-compat/libnss-compat-1.2.ebuild | 43 +++++++++++++++++++++++++ sys-auth/libnss-compat/metadata.xml | 7 ++++ 3 files changed, 51 insertions(+)}
With above new package I think we can close this now.
After upgrading to glibc-2.26, I added the libnss-compat packages as suggested in this report and the compat functionality is still not working. Adding libnss-nis and using nis instead of compat in the nsswitch.conf file is working, but on a couple of machines, I need the compat capabilities. Other that emerging libnss-compat, what needs to be done to restore the compat capability?
> Good /etc/nsswitch.conf: > group: files having only "files" for "group:" seem to lead to another problem: when using the glibc's getent utility or perl's "getgrent" to query "group" then lines in /etc/group that exceed 762 characters are silently skipped in output/return. if the same "oversized" line is repeated then one of them is printed. reapeated again n-1 are printed. very odd. i sometimes use this to query group-membership information. this is now broken for groups with more than "some" members. also reproducible in 2.27. got a PI here with newer 2.28 on it (archlinux) - longer lines with >762 chars are displayed correctly. same with old 2.21.
(In reply to Nico Rittner from comment #31) > > Good /etc/nsswitch.conf: > > group: files > > having only "files" for "group:" seem to lead to another problem: > when using the glibc's getent utility or perl's "getgrent" to query "group" > then lines in /etc/group that exceed 762 characters are silently skipped in > output/return. if the same "oversized" line is repeated then one of them is > printed. reapeated again n-1 are printed. very odd. i sometimes use this to > query group-membership information. this is now broken for groups with more > than "some" members. also reproducible in 2.27. got a PI here with newer > 2.28 on it (archlinux) - longer lines with >762 chars are displayed > correctly. same with old 2.21. Please report as a new bug. Ideally with group contents and exact command to exercise the bug.
