Hi folks,
As of glibc 2.32, upstream has split out RPC support; if you want RPC functionality, you now need to link against libtirpc instead, which is a superior, more featureful implementation.
This is a good thing architecturally, but one of the side effects for us is that, via PAM, we are now pulling a large number of crypto libraries into
the transitively-essential set, because pam_unix links against libtirpc for NIS / NIS+ support.
Sam Hartman made a valiant attempt to make this an optional dynamic dependency, but ultimately abandoned the effort.
So I'd like to take a step back and challenge an underlying assumption by asking: do any of our users actually *need* this functionality? The RPC functionality is only used for NIS and NIS+. NIS is historically quite insecure, and I'm not aware of any efforts to improve its security (AFAIK
the linkage of the crypto libraries doesn't fix the fundamentally insecure interfaces of NIS). NIS+ is intended to be a more secure version of NIS, but to my knowledge there has never been a free implementation in the archive; this was a Sun-specific technology, which Sun deprecated two
decades ago[1].
If we dropped support for NIS and NIS+ in the next Debian release, would anybody miss it? Or has everyone moved on to LDAP / AD by now?
So I'd like to take a step back and challenge an underlying assumption by asking: do any of our users actually *need* this functionality? The RPC functionality is only used for NIS and NIS+. NIS is historically quite insecure, and I'm not aware of any efforts to improve its security (AFAIK
the linkage of the crypto libraries doesn't fix the fundamentally insecure interfaces of NIS). NIS+ is intended to be a more secure version of NIS,
but to my knowledge there has never been a free implementation in the archive; this was a Sun-specific technology, which Sun deprecated two
decades ago[1].
If we dropped support for NIS and NIS+ in the next Debian release, would anybody miss it? Or has everyone moved on to LDAP / AD by now?
Before any discussion takes place, I would like to point out a previous attempt of Fedora trying to get rid of NIS/NIS+ back in 2021. Please check out
the LWN article at https://lwn.net/Articles/874174/ , which would definitely be helpful for the condition in Debian.
Hi,
On Wed, Apr 20, 2022 at 04:26:02PM -0400, Boyuan Yang wrote:
Before any discussion takes place, I would like to point out a previous attempt of Fedora trying to get rid of NIS/NIS+ back in 2021. Please check out
the LWN article at https://lwn.net/Articles/874174/ , which would definitely
be helpful for the condition in Debian.
That discussion seems to be about removing NIS/NIS+ support from the
entire distribution. This thread is about removing NIS support from PAM. That's an important distinction, because in practice, NIS/NIS+ support
mostly means the NSS modules, and the tools/servers in the case of NIS.
Dropping NIS support from PAM would mean losing only the ability to
change the passwords of users coming from NIS. It would not affect user lookups, and password change would still be possible using yppasswd.
There does not even seem to be any NIS+ support in PAM - nothing seems
to include <rpcsvc/nis.h>.
Personlly, I think bundling NIS password changing capability in pam_unix
was a design mistake. It should always have been a distinct module.
Before any discussion takes place, I would like to point out a previous attempt of Fedora trying to get rid of NIS/NIS+ back in 2021. Please check out
the LWN article at https://lwn.net/Articles/874174/ , which would definitely
be helpful for the condition in Debian.
That discussion seems to be about removing NIS/NIS+ support from the
entire distribution. This thread is about removing NIS support from PAM. That's an important distinction, because in practice, NIS/NIS+ support mostly means the NSS modules, and the tools/servers in the case of NIS.
Dropping NIS support from PAM would mean losing only the ability to
change the passwords of users coming from NIS. It would not affect user lookups, and password change would still be possible using yppasswd.
There does not even seem to be any NIS+ support in PAM - nothing seems
to include <rpcsvc/nis.h>.
Personlly, I think bundling NIS password changing capability in pam_unix was a design mistake. It should always have been a distinct module.
Can we provide a separately packaged pam_unix_nis which can be used
instead of pam_unix in cases where this functionality is still
required?
Doing a quick check, PAM only seems to rely on the RPC libraries for
changing NIS passwords. Personally, I think losing that would not be a
big deal. While I can still see NIS being useful in some corners of the world, I cannot imagine such an environment wanting to enforce password expiration. And if you don't expire passwords, then you don't need PAM
to be able to change passwords - running yppasswd should be fine for voluntary password changes.
Before any discussion takes place, I would like to point out a previous attempt of Fedora trying to get rid of NIS/NIS+ back in 2021. Please
check out the LWN article at https://lwn.net/Articles/874174/ , which
would definitely be helpful for the condition in Debian.
On Fri, 22 Apr 2022 13:41:50 -0700, Steve Langasek <vorlon@debian.org> said:
I'm using NIS since 20+ years in a small network with about 60 computers. Since I manage all computers and the physical network can be seen as secure (I know it's not perfect secure) I do not need the additional crypto
features of NIS+ or LDAP, which would be overkill. All my users use
yppasswd on the NIS master for changing their password. I guess I
still need pam support for this because I set things like this in pam.d/common-password:
password requisite pam_cracklib.so retry=3 difok=3 minlen=14
Yes, I surely would miss the NIS support.
On Fri, 22 Apr 2022 13:41:50 -0700, Steve Langasek <vorlon@debian.org> said:
...
On Fri, Apr 22, 2022 at 10:07:52PM +0200, lange@debian.org wrote:
I'm using NIS since 20+ years in a small network with about 60 computers. Since I manage all computers and the physical network can be seen as secure (I know it's not perfect secure) I do not need the additional crypto features of NIS+ or LDAP, which would be overkill. All my users use yppasswd on the NIS master for changing their password. I guess I
still need pam support for this because I set things like this in pam.d/common-password:
password requisite pam_cracklib.so retry=3 difok=3 minlen=14
Yes, I surely would miss the NIS support.
If your users are using yppasswd on the NIS master for changing passwords, then evidently you are not relying on support for NIS in PAM. (yppasswd doesn't even link against libpam.)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 168:43:36 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,551 |