(In reply to Trond H. Amundsen from comment #0)
> Not sure what the correct solution is, but it is clearly wrong to assume
> that compat is only used with NIS.

nsswitch.conf(5) strongly suggests that only nis and nisplus are supported.  The package layout was based on that.  We can reconsider it if compat with non-NIS service modules is indeed a supported scenario.

(In reply to Florian Weimer from comment #1)
> nsswitch.conf(5) strongly suggests that only nis and nisplus are supported. 
> The package layout was based on that.  We can reconsider it if compat with
> non-NIS service modules is indeed a supported scenario.

Hmm.. I fail to see that the man page strongly suggests anything like that. It states that:

       By default, the source is "nis", but this may be overridden by specify‐
       ing any NSS service except  "compat"  itself  as  the  source  for  the
       pseudo-databases passwd_compat, group_compat, and shadow_compat.

I can agree that using compat with SSSD is unusual, and I can't say if it is "officially supported" or not, but it works :)

PS. For anyone encountering this issue: Easy workaround is to make sure that ypbind is installed prior to upgrade. In F25, the ypbind rpm requires nss_nis.

-trond

nsswitch.conf in Fedora 23 still says this:

       By default, the source is "nis", but this may be overridden by specifying
       "nisplus"   as   the   source  for  the  pseudo-databases  passwd_compat,
       group_compat, and shadow_compat.

I didn't realize the manual pages were updated.

Ah.. you were referring to the actual nsswitch.conf file, not the man page, sorry for the confusion. I haven't read the contents of the default nsswitch.conf for years.

Anyway, in my opinion this is a bug that should be fixed. Usually, I would think that the logical solution is to move the compat libs into the main package, but since the main package is glibc that would contradict the glibc->nss split. 

Perhaps the best option is to move libnss_compat into a separate package, e.g. nss_compat, and work with maintainers of sssd etc. to get the dependencies right.

(In reply to Trond H. Amundsen from comment #4)
> Ah.. you were referring to the actual nsswitch.conf file, not the man page,
> sorry for the confusion. I haven't read the contents of the default
> nsswitch.conf for years.
> 
> Anyway, in my opinion this is a bug that should be fixed. Usually, I would
> think that the logical solution is to move the compat libs into the main
> package, but since the main package is glibc that would contradict the
> glibc->nss split. 
> 
> Perhaps the best option is to move libnss_compat into a separate package,
> e.g. nss_compat, and work with maintainers of sssd etc. to get the
> dependencies right.

I would like to understand your use case better before we decide on a course of action. Your input will help us understand the extent to which we may need to discuss these changes.

When you configured this system why did you consider using 'compat'?

Were you originally using NIS with 'compat' and then migrated the NIS server to SSSD and therefore wanted an easy way to convert the system over?

Was this a newly configured system and you wanted the 'compat' functionality that allows singular users to be pulled into the database e.g +user?

Thanks for your input.

(In reply to Carlos O'Donell from comment #5)

> I would like to understand your use case better before we decide on a course
> of action. Your input will help us understand the extent to which we may
> need to discuss these changes.
> 
> When you configured this system why did you consider using 'compat'?
> 
> Were you originally using NIS with 'compat' and then migrated the NIS server
> to SSSD and therefore wanted an easy way to convert the system over?
> 
> Was this a newly configured system and you wanted the 'compat' functionality
> that allows singular users to be pulled into the database e.g +user?

Ok, you asked for it :) Here is the brief and simplified NSS history at the University of Oslo. We started using NIS in the early 90's, I believe (before my time). At some point (also before my time) we switched to compat with NIS. We're still using compat/NIS on the very few remaining RHEL5 hosts (ugh), but from RHEL6 onwards we switched to compat/SSSD, with LDAP as backend for SSSD. The reason for choosing SSSD was its excellent caching functionality, among other things. We never considered NIS+.

The rationale behind compat is that we have a lot of users (about 50k), managed centrally in LDAP. We obviously don't want all users to be known on all Linux hosts, and with a de-centralized organization it has become important to have a consistent, quick and easy way to manage known users on Linux hosts. Since it's been this way for decades, everybody knows that in order to allow a user on Linux host, all you need is to add "+user" or "+@netgroup" in passwd. This approach has served us very well.

All hosts are configured using a centrally managed config management system (CFEngine), so that all systems are convergent and users/admins can expect the same basic behaviour from all of them.

PS. As we've already put a workaround in place for this particular bz, my interest in this bug is only to improve Fedora.

(In reply to Trond H. Amundsen from comment #6)
> The rationale behind compat is that we have a lot of users (about 50k),
> managed centrally in LDAP. We obviously don't want all users to be known on
> all Linux hosts, and with a de-centralized organization it has become
> important to have a consistent, quick and easy way to manage known users on
> Linux hosts. Since it's been this way for decades, everybody knows that in
> order to allow a user on Linux host, all you need is to add "+user" or
> "+@netgroup" in passwd. This approach has served us very well.

So this is what I thought you were going to say.

What happens if you just remove compat and expose all 50k users to everyone via SSSD?

It would elimitate the need to do any kind of "+user" or "+@netgroup" additions?

Are you able to test this on just one box?

(In reply to Carlos O'Donell from comment #7)

> What happens if you just remove compat and expose all 50k users to everyone
> via SSSD?

That would work just fine on a technical level, but then we wouldn't have the kind of fine-masked access control that we want.

> It would elimitate the need to do any kind of "+user" or "+@netgroup"
> additions?

Yes, all users would be known. Also, the "+user" or "+@netgroup" syntax wouldn't be legal as it isn't passed through nss_compat.

> Are you able to test this on just one box?

Don't need to test it, I know that it works :) But as I said, we want the ability to say that only these netgroups or users should be allowed to log in on a particular machine, and nss_compat is by far the easiest and most scalable way to achieve that.

(In reply to Trond H. Amundsen from comment #8)
> (In reply to Carlos O'Donell from comment #7)
> 
> > What happens if you just remove compat and expose all 50k users to everyone
> > via SSSD?
> 
> That would work just fine on a technical level, but then we wouldn't have
> the kind of fine-masked access control that we want.

Why do you want fine-masked access control?

What do you gain from it?

I'm trying to more deeply understand the problem you're solving.

> > It would elimitate the need to do any kind of "+user" or "+@netgroup"
> > additions?
> 
> Yes, all users would be known. Also, the "+user" or "+@netgroup" syntax
> wouldn't be legal as it isn't passed through nss_compat.

Correct, but you wouldn't need "+user" or "+@netgroup" anymore?

> > Are you able to test this on just one box?
> 
> Don't need to test it, I know that it works :) But as I said, we want the
> ability to say that only these netgroups or users should be allowed to log
> in on a particular machine, and nss_compat is by far the easiest and most
> scalable way to achieve that.

I guess this answers my question about why you want this feature.

Two suggestions:

(1) Use /etc/security/access.conf for group-based access to logins.

(2) Use PAM to do group-based logins.

Use pam_listfile (http://www.linux-pam.org/Linux-PAM-html/sag-pam_listfile.html, with item=group or item=user) since it is designed and tested for this kind of functionality.

Otherwise you are using a legacy feature to do access control to logins. You indirectly rely on the fact that PAM already has 'account required pam_permit.so' for most PAM-aware services (like login).

This is not a well tested feature combination for glibc nor a normally supported configuration outside of testing legacy support for the compat features.

Would PAM or access.conf group-based login work for you?

(In reply to Carlos O'Donell from comment #9)

> Why do you want fine-masked access control?
> 
> What do you gain from it?

These are not easy questions to answer, but I'll do my best. To really understand why this is so valuable you need know how we're organized. This is a university, which has a lot of students, faculty, staff and other personnel that have user accounts. All accounts are managed centrally, but the users are organized mostly hierarchically in faculties, institutes and other departments. Each department/institute etc. usually have their own IT staff, that have privileges on "their" hosts. The local IT staff can delegate privileges to their users, e.g. "power users" may have administrative privileges on some hosts.

We make heavy use of netgroups to organize this in the IT world. These are also managed centrally, but local IT staff can often add and remove users from "their" netgroups.

We need an easy and understandable way for IT staff and "power users" to control access to hosts. For example, the Physics department usually don't want users from other departments on their equipment, and they may want to limit certain hosts to only students on a particular course, or only members of a particular research group. Linux knowledge across IT staff and users vary greatly, so this needs to be easy, understandable and consistent across OS releases.

So, we're de-centralized but with some central control. We use config management (in our case CFEngine) to manage aspects of the hosts that we consider important for security or consistency reasons. Login and access control mechanisms fall into that category, but employing these mechanisms is delegated.

> > > It would elimitate the need to do any kind of "+user" or "+@netgroup"
> > > additions?
> > 
> > Yes, all users would be known. Also, the "+user" or "+@netgroup" syntax
> > wouldn't be legal as it isn't passed through nss_compat.
> 
> Correct, but you wouldn't need "+user" or "+@netgroup" anymore?

As long as we have another mechanism to achieve the same functionality, we don't need it. We use the "+foo" syntax to achieve two things, one of which I forgot to mention earlier:

1. Simple access control
2. Overriding fields in passwd, usually home directory or shell

> Two suggestions:
> 
> (1) Use /etc/security/access.conf for group-based access to logins.
> 
> (2) Use PAM to do group-based logins.
> 
> Use pam_listfile
> (http://www.linux-pam.org/Linux-PAM-html/sag-pam_listfile.html, with
> item=group or item=user) since it is designed and tested for this kind of
> functionality.
> 
> Otherwise you are using a legacy feature to do access control to logins. You
> indirectly rely on the fact that PAM already has 'account required
> pam_permit.so' for most PAM-aware services (like login).

The important parts of the PAM stack are managed centrally with config management, so we do have control over that part.

> This is not a well tested feature combination for glibc nor a normally
> supported configuration outside of testing legacy support for the compat
> features.
> 
> Would PAM or access.conf group-based login work for you?

I can't say yes or no to that. To be honest, nss_compat has worked so well for us, and for so long, and across various (now deprecated) UNIX variants and Linux, that we haven't really questioned it. It just works. But perhaps it's time to take a step back and evaluate this practice.

I do know that changing something this fundamental (for us) can't be done in a heartbeat. We'll need to do this when adding a new distro version, such as a new version of Fedora and later RHEL8. But first we need to evaluate our options. Thanks for your feedback, suggestions and insight :)

*** Bug 1401046 has been marked as a duplicate of this bug. ***

Upstream consensus has changed and compat is no longer consider NIS-specific.  Andreas Schwab posted a patch which removes the libnsl dependency:

https://sourceware.org/ml/libc-alpha/2017-10/msg00157.html

I'll backport this change once it's in upstream master.

glibc-2.26-12.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-0d3fdd3d1f

glibc-2.26-12.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-0d3fdd3d1f

glibc-2.25-11.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-2c63df4fe3

glibc-2.26-13.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-0d3fdd3d1f

glibc-2.25-11.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-2c63df4fe3

glibc-2.26-13.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-0d3fdd3d1f

glibc-2.25-12.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-2c63df4fe3

glibc-2.25-12.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-2c63df4fe3

glibc-2.26-14.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-0d3fdd3d1f

glibc-2.26-14.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-0d3fdd3d1f

glibc-2.26-15.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-0d3fdd3d1f

glibc-2.26-15.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-0d3fdd3d1f

glibc-2.26-15.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

glibc-2.25-12.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.