Bug#978600: Substantial increase in pseudo-Essential due to libnsl2 and libtirpc3 (and dependencies)
Josh, I took a look at writing a patch to implement dlopen of the appropriate RPC libraries for NIS support in pam. It looked a bit more thorny than I'd feel comfortable with unless I had substantial review, and it looks like my non-Debian commitments are picking up. Thoughts: * If it's going to happen for bullseye, it needs to be written, reviewed and uploaded by the 12th. * If it's going to happen it needs to not be vetoed by Steve. (Steve said he'd be happy with my help on PAM this week, but he's still the maintainer) * I'd want an independent review of the patch from someone different from whoever wrote it. I'd want the reviewer and the author to test the patch against a NIS environment. Based on my schedule that basically means that someone would need to write a patch, test it, and propose by Saturday. If that happens I'll commit to reviewing, testing, and if we can resolve any issues that come up, uploading. My review criteria would be: 1) Confidence that the patch does not introduce new security problems. The control flow in pam_unix_password.c is already kind of complex, and it seems like it would be easy to introduce bugs by changing that. 2) Maintenance. Is it likely that Debian's going to be able to carry the patch long-term? I doubt we'll see upstream take the patch. One test of this will be to confirm that the patch is easy to deal with for the 1.4.0 release of PAM in Debian and the 1.5.1 release upstream. But there's also a subjective judgment. 3) Ability to detect changes in dependencies. Presumably we'd move dependencies to recommends rather than depends. I'd want to review and make sure we were likely to detect those recommends becoming out of date. One way to handle that would be to produce an autopkgtest that tested the NIS code. (PAM currently has no autopkgtests). It's possible that if we had a plan, that could be deferred a bit in implementation, so long as we had something in place when things thaw. Honestly, what I'm proposing is a tight schedule. So I suspect this isn't happening for bullseye. But I wanted to let you know where my availableavailability as a PAM uploader was, and that I didn't have time to write the patch myself. --Sam signature.asc Description: PGP signature
Bug#978600: Substantial increase in pseudo-Essential due to libnsl2 and libtirpc3 (and dependencies)
On Tue, 29 Dec 2020 14:52:17 +0100 Ansgar wrote: > On Mon, 2020-12-28 at 20:34 -0800, Josh Triplett wrote: > > - Make pam_unix dlopen the necessary libraries > [...] > > - Build pam_unix with and without NIS support, and make libpam- > > modules > > Wouldn't it be cleaner to move NIS stuff into its own PAM module, > i.e. a pam_nis? Yes, absolutely. Unfortunately, pam_unix has historically had NIS support built-in rather than as a separate module, so at the very least, moving that to a separate module would require a *very careful* configuration migration. And compared to other possibilities, editing existing PAM configuration seems extremely error-prone. That would also be a divergence from upstream PAM. For all those reasons, I'd be extremely hesitant to advocate such an approach. That said, if that were the approach the PAM maintainers would prefer, I'd be happy to help implement it. It seems more robust to either dlopen NIS support or ship two versions of pam_unix. Both of those would keep existing configurations working entirely unmodified. The former approach would involve a NEWS.Debian entry telling the user to install NIS libraries if needed; the latter would involve either a package with the NIS version of pam_unix and a diversion, or two mutually exclusive packages. > > - Migrate libpam-modules itself towards dropping the Essential flag. [For clarity, this would be a much larger task, and I'm not proposing doing this quickly. I think it would make more sense to take one of the other steps first.] > Do utilities like `su` or `sudo` still work w/o libpam-modules > installed (at least for root)? No, by design they would not; if you want to use either of those, or otherwise support interactive users, you'd need PAM installed and configured. sudo already depends on libpam-modules. passwd does as well. setuid/setgid programs would still work. And there are several tools that can run programs as a different user: setpriv for interactive or script use as root, start-stop-daemon for init scripts, systemd's User and Group directives, runit's chpst, and likely others. So it would still be possible to run programs as other users, and to drop privileges; it just wouldn't be possible to interactively authenticate to gain privileges. Any system with interactive users almost certainly wants PAM. Embedded systems, special-purpose servers, and containers/chroots don't necessarily need it, though. > Is it possible to log in to a system w/o libpam-modules installed? > Via OpenSSH public key auth? Via local console? It's possible to log in via OpenSSH or Dropbear or similar, if configured to not use PAM. OpenSSH does have a hard dependency on libpam-modules, but dropbear would work (and it's a common choice on embedded systems).
Bug#978600: Substantial increase in pseudo-Essential due to libnsl2 and libtirpc3 (and dependencies)
On Tue, Dec 29, 2020 at 06:34:35AM -0500, Sam Hartman wrote: > > "Josh" == Josh Triplett writes: > Josh> I'm happy to contribute towards any of these paths, or another > Josh> path that would avoid expanding the pseudo-Essential set. > > Josh, I found your message fairly frustrating, because you jumped > immediately to the assumption that we want to limit the pseudo-essential > set in this way. That wasn't the intention. I wasn't asking people to actively contribute towards that goal; I was seeking feedback on potential solutions, prior to putting in implementation effort. I was also raising the issue on -devel, because changes in Essential/pseudo-Essential typically get discussed there, and this one hadn't been as far as I could find. I realize that often, in such discussions, people reporting bugs or making feature requests may be expecting others to do the work of implementing such solutions. I was trying to avert that. I started with the baseline assumption that anyone wanting to see the pseudo-Essential set shrink or even remain at the same size would also have to step up and do the work; I wanted to start that discussion and offer to help. I wasn't assuming that everyone agreed with that goal. It certainly didn't cross my mind to think my message made any assumptions that could generate a strong negative reaction. Based on the functionality factored out of libc6 and the transitional handling of those libraries (treating them as successors and adding temporary -dev dependencies but avoiding runtime dependencies so that the libraries would be possible to remove in the future), I thought it would help to catch a case that might otherwise potentially result in a multi-release challenge in trying to remove such packages. Packages in the pseudo-Essential set, while not Essential themselves, can be quite challenging to remove once released; other packages may have implicit assumptions about their presence. So, to restate explicitly: - If we're going to handle this, I think it'll be *much* easier to do so before it hits stable. - I'm willing to help with this. - I'd like to figure out the best approach to handling this. > I'm not involved in PAM these days, so consider this the opinion of an > outside bystander. > > I think it would be most interesting to see about dllopening the NIS > support. > That seems least invasive to sysadmin experience--if you have NIS > installed at the libc6 nsswitch layer, you can also get it at the pam > layer. That seemed like the least invasive option to me, as well. Long-term, I think it may still make sense to make PAM non-Essential, but I think that'd be a substantially larger change, and one that would require more time.
Bug#978600: Substantial increase in pseudo-Essential due to libnsl2 and libtirpc3 (and dependencies)
On Mon, 2020-12-28 at 20:34 -0800, Josh Triplett wrote: > - Make pam_unix dlopen the necessary libraries [...] > - Build pam_unix with and without NIS support, and make libpam- > modules Wouldn't it be cleaner to move NIS stuff into its own PAM module, i.e. a pam_nis? > - Migrate libpam-modules itself towards dropping the Essential flag. Do utilities like `su` or `sudo` still work w/o libpam-modules installed (at least for root)? Is it possible to log in to a system w/o libpam-modules installed? Via OpenSSH public key auth? Via local console? Ansgar
Bug#978600: Substantial increase in pseudo-Essential due to libnsl2 and libtirpc3 (and dependencies)
> "Josh" == Josh Triplett writes: Josh> I'm happy to contribute towards any of these paths, or another Josh> path that would avoid expanding the pseudo-Essential set. Josh, I found your message fairly frustrating, because you jumped immediately to the assumption that we want to limit the pseudo-essential set in this way. That may be obvious to you, but it doesn't seem like it has been obvious to the project in general. I mean I think there's general agreement smaller good in some abstract sense. But I don't know that there's agreement about which changes we want to work toward and how much effort we want to engage in in order to accomplish the goal of limiting the pseudo essential set. I would have found your communication more inclusive and easier to approach if you had started by 1) Acknowledging that conversation was not foregone 2) Engaging there Once I take a few deep breaths and get over my initial frustration, approaching the options you outlined. I'm not involved in PAM these days, so consider this the opinion of an outside bystander. I think it would be most interesting to see about dllopening the NIS support. That seems least invasive to sysadmin experience--if you have NIS installed at the libc6 nsswitch layer, you can also get it at the pam layer.
Bug#978600: Substantial increase in pseudo-Essential due to libnsl2 and libtirpc3 (and dependencies)
Package: libpam-modules Version: 1.4.0-1 Severity: normal X-Debbugs-Cc: j...@joshtriplett.org, debian-de...@lists.debian.org The new pam 1.4.0 has switched pam_unix from libnsl.so.1 (in libc6) to libnsl2 and libtirpc3, which brings those packages into the pseudo-Essential set. This is a rather substantial increase in the number of pseudo-Essential packages; it also pulls in libgssapi-krb5-2, libkrb5-3, libtirpc-common, libk5crypto3, libkrb5support0, and libkeyutils1. In addition, it adds a second dependency on libcom-err2, which was otherwise only pulled in by e2fsprogs (Essential but generally safely removable). I realize it makes sense to migrate from the previous libc-provided RPC/NIS support to the separate libraries. However, this seems likely to make those libraries quite difficult to remove from pseudo-Essential in the future. I'm reporting this issue as soon as I noticed it, in the hopes that it might be possible to mitigate this before the the next stable release, before it becomes further entrenched and migrations become more challenging. A few possible ideas for how to address this: - Make pam_unix dlopen the necessary libraries, which (given sufficient notice) would allow dropping the hard dependency. Considering that libc6 already only Recommends the NSS modules for NIS, it seems reasonable to follow suit here. - Build pam_unix with and without NIS support, and make libpam-modules Pre-Depends on a non-Essential "libpam-unix-nis | libpam-unix". (This seems rather more invasive, but cleaner long-term.) - Migrate libpam-modules itself towards dropping the Essential flag. PAM no longer "fails open" in the absence of configuration or specified modules, so this should be safe. A system without PAM still functions, and just doesn't support PAM authentications/sessions/etc; this doesn't seem any more unreasonable than making init non-Essential (because chroots and some containers don't need it), or eventually making login non-Essential (because systems without interactive console login don't need it). I'm happy to contribute towards any of these paths, or another path that would avoid expanding the pseudo-Essential set.
