Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#45903 - [pam systemd] Disable obsolete pam_securetty.so

Attached to Project: Arch Linux
Opened by Kai Hendry (hendry) - Wednesday, 05 August 2015, 13:55 GMT
Last edited by David Runge (dvzrv) - Thursday, 21 November 2019, 18:43 GMT
Task Type General Gripe
Category Packages: Testing
Status Assigned
Assigned To Tobias Powalowski (tpowa)
Evangelos Foutras (foutrelis)
Dave Reisner (falconindy)
Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 22
Private No

Details

Description: securetty hinders a root login from a host to a container. As I understand it, it's function is obsolete as argued by Lennart in https://github.com/systemd/systemd/issues/852#issuecomment-127759667


Additional info:
* 1.2.0-1


Steps to reproduce:

Login as root to a pacstrapped container.
This task depends upon

Comment by t-ask (tAsk) - Wednesday, 31 October 2018, 13:11 GMT
You can fix this by removing `/ect/securetty` from the container itself. Still the question persists if `securetty` is still needed nowadays.
Comment by Johannes Ernst (jernst) - Thursday, 10 October 2019, 07:31 GMT Comment by Daan De Meyer (DaanDeMeyer) - Monday, 11 November 2019, 17:58 GMT
Another vote for removing pam_securetty as the same was done by Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1090639, https://bugzilla.redhat.com/show_bug.cgi?id=1090638). https://lists.fedoraproject.org/pipermail/devel/2014-April/197712.html goes into more detail into the reasoning behind the change. I think pam_securetty is the only thing left that's blocking seamless root login on pacstrapped containers which is tremendously convenient for containers used as development environments. Right now, when root login fails it's not trivial to figure out that the cause is pam_securetty.
Comment by Daan De Meyer (DaanDeMeyer) - Monday, 18 November 2019, 18:35 GMT
Relevant Debian bug report (who also removed /etc/securetty and are likely to disable pam_securetty as well): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731656
Comment by Christian Rebischke (Shibumi) - Thursday, 21 November 2019, 19:55 GMT
This issue can be fixed via adding "pts/n", (where n is an integer from 0 to 10) for example "pts/0", to your container.
Comment by Daan De Meyer (DaanDeMeyer) - Thursday, 21 November 2019, 20:19 GMT
That works but I'd prefer to be able to login without having to change each and every Arch container I ever pacstrap. Especially with other major distributions opting to remove /etc/securetty as well, it's not like we're breaking new ground here if we're just following Fedora and Debian (with several statements from Poettering in systemd github issues strongly discouraging the use of pam_securetty as well).
Comment by Daan De Meyer (DaanDeMeyer) - Friday, 22 May 2020, 18:20 GMT
We're at 18 votes already. Can we at least get a decent explanation for why we're not removing this? It's just not a productive use of everyone's time to work around this every time they encounter it. Let's fix the problem once and for all by just disabling the module just like all the other big distros have done.
Comment by Christian Rebischke (Shibumi) - Friday, 22 May 2020, 22:30 GMT
@daan

you can also have a look at https://nspawn.org, nspawn.org provides arch linux tarballs with unlocked pts.
Comment by Tobias Powalowski (tpowa) - Tuesday, 21 July 2020, 13:25 GMT
Should be fixed in 1.4.0-2
Comment by nl6720 (nl6720) - Tuesday, 21 July 2020, 14:29 GMT
pam 1.4.0-2 still has /usr/lib/security/pam_securetty.so, but before it can be removed, other packages need to be fixed:

$ grep -Flr pam_securetty.so /etc/pam.d | pacman -Qo -
/etc/pam.d/login is owned by util-linux 2.35.2-1
/etc/pam.d/rlogin is owned by inetutils 1.9.4-8
/etc/pam.d/rsh is owned by inetutils 1.9.4-8
/etc/pam.d/sshd is owned by openssh 8.3p1-3


The easy fix with an immediate effect is to remove /etc/securetty and /usr/share/factory/etc/securetty from the filesystem package.
Comment by loqs (loqs) - Friday, 24 July 2020, 17:39 GMT
@nl6720 why would pam_securetty.so have to be removed if its use was removed from the default pam configurations?
Is the intention to prevent a user from re-enabling pam_securetyy.so?

/etc/pam.d/sshd contains:

#auth required pam_securetty.so #disable remote root

why would a commented out line need adjustment?
Edit:
What if the change was limited to the removal of pam_securetty.so from /etc/pam.d/login?
Comment by nl6720 (nl6720) - Saturday, 25 July 2020, 12:01 GMT
@loqs, of course the pam module doesn't need to be removed from the package if the configurations are altered.
I interpreted this issue as asking for the complete removal of pam_securetty.so. If that is not the case, then it shouldn't have been reported against pam, but against the packages which ship with pam configuration that requires pam_securetty.so, i.e. (util-linux, inetutils, etc.), or against filesystem since it provides /etc/securetty and /usr/share/factory/etc/securetty.
Comment by loqs (loqs) - Saturday, 25 July 2020, 14:21 GMT
util-linux drop pam_securetty.so from /etc/pam.d/login

inetutils uses pam_securetty.so to prevent root logins via rlogin or rsh in plain text.

openssh similarly to inteutils has a a commented out pam entry to prevent root logins, openssh's PermitRootLogin option provides the same functionality.

Loading...