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).
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 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?
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.
You can fix this by removing `/ect/securetty` from the container itself. Still the question persists if `securetty` is still needed nowadays.
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.
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).
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.
@daan
you can also have a look at https://nspawn.org, nspawn.org provides arch linux tarballs with unlocked pts.
Should be fixed in 1.4.0-2
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.
@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?
@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.
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.