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 the AUR. 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 24
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.
Comment by tinywrkb (tinywrkb) - Thursday, 27 May 2021, 17:40 GMT
Can this be moved forward? is the only blocker are inetutils's rlogind and rshd? maybe just disable them in the package or send the whole thing to the AUR and add a symlink to gettext's hostname implementation as a gettext-hostname package (and switch packages to depend on hostname).
Is having systemd-nspawn login broken is the desired behavior?
I get that some users need the inetutils' clients but there are probably much more users who prefer to have a working systemd-nspawn login than those who need inetutils' daemons.
Comment by loqs (loqs) - Thursday, 27 May 2021, 20:01 GMT
tinywrkb have you been through all the packages which have a dependency on inetutils and checked what components from inetutils they require?
There is an effort to switch upstream projects from hostname to uname -n but that does not work for hostname -f.
Another option to the gettext supplied hostname would be the hostname package supplied by Debian also used by Fedora.
Comment by tinywrkb (tinywrkb) - Thursday, 27 May 2021, 21:04 GMT
@loqs I only quickly glance at this but most packages that depends on inettuils only need it for make or check functions and what I've seen so far suggest this most likely just for hostname but we still need to see that every package builds correctly with just hostname.

There are a few outdated packaging that don't need hostname anymore:
* profile-sync-daemon: https://github.com/graysky2/profile-sync-daemon/commit/959789e514622d6bf9b9b52fe696d089029ed33e
* testssl.sh: https://github.com/drwetter/testssl.sh/commit/09c276ffa2df590b627f84534bf36ed5cae36ddc
* grml-zsh-config: https://github.com/grml/grml-etc-core/commit/41249966740c33a591b9dcc14edc37ddaa595bb6

And the only packages left are:
* cvs: optionally need rsh so it's not a blocker
* archboot: I'm not completely sure but I think it's only need hostname though it still installs dnsdomainname
* posix-user-portability: that's basically a meta package so pit's retty safe to drop the inetutils dependency
* metasploit: I'm not sure about this
* x2goserver: I'm not sure about this also. without looking into the code I would guess that it might optionally use rsh or rlogin for remote connection

And again, everything left I believe just need hostname and it's mostly for make or make test.
Comment by tinywrkb (tinywrkb) - Thursday, 27 May 2021, 21:08 GMT
p.s. The first change that we need is to have inetutils provide hostname, the package maintainers should switch to depend on hostname where it's possible, and it probably won't take much time to find out that the inetutils package is not very useful.
Comment by loqs (loqs) - Thursday, 27 May 2021, 21:31 GMT
I would suggest splitting inetutils into functional groups:
hostname/dnsdomainname
rcp/rlogin/rlogind/rsh
ftp/ftpd
talk/talkd
telnet/telnetd

seabios does not use hostname any more (also does not build currently) will bug that in a bit.
thunderbird and ncftp do not use hostname anymore have bugged those.
I think metaspolit provides its own implementation of hostname but that needs checking.
boinc uses hostname during build and check looks to be a trivial change to be upstreamed.
x2goserver uses hostname at runtime again looks to be a trivial change to upstream.
tbb no longer uses hostname upstream wait for next release
nvidia-settings, I think this has stopped hostname, again needs checking.
imapsync uses hostname to work out if it is being built on the upstream developers own box during check in order to run different tests.
rabbitmq change the .install script to use `uname -n` and change the depends to makedepends?
pcp uses hostname in multiple runtime scripts. This looks like it will take some work to switch to `uname -n`.
netsurf should be able to drop inetutils, set $HOSTNAME to some reproducible value or unset it.
gcc uses hostname during one D test, hopefully upstream would accept a patch switching it to `uname -n`, skips the test if not present.
dotnet-core, builds without inetutils.
netcdf-openmpi two test failures unrelated to removing inetutils from checkdepends, DNC_CTEST_SITE=`uname -s`.
crystal, builds without inetutils.
python-h5py-openmpi, does not use inetutils.
python-mpi4py, does not use inetutils.
monitoring-plugins checks for hostname in configure AC_PATH_PROG(HOSTNAME,hostname) but never uses hostname or HOSTNAME?
Comment by tinywrkb (tinywrkb) - Friday, 28 May 2021, 10:52 GMT
> I would suggest splitting inetutils into functional groups:
> hostname/dnsdomainname

That's a good idea. This way user could still use an alternative hostname implementation but still install the other utils/daemons. The package should still have a provides array for hostname.

> rcp/rlogin/rlogind/rsh
> ftp/ftpd
> talk/talkd
> telnet/telnetd

Most users probably won't need any of these so I think it's better to keep it simple and have them in a single package.

Maybe we can avoid having to coordinate with all the relevant package maintainers by changing inetutils into a meta package that will install inetutils-nameutils (hostname & dnsdomainname) and inetutils-archaic (all other, needs a better name).
Comment by loqs (loqs) - Friday, 28 May 2021, 23:36 GMT
x2go-server-4.1.0.3-uname.patch replaces hostname with uname. This should be upstreamed. x2go-server-upstream.patch is the same patch with context adjusted for upstream.

PKGBUILD.inetutils is a split package version of the package, I did the split as I originally suggested but rearranging that is not an issue.

If pam_securetty is going to be kept anywhere and /etc/securetty dropped then I would suggest cherry-picking https://github.com/linux-pam/linux-pam/commit/e842a5fc075002f46672ebcd8e896624f1ec8068
I also think the man page for pam_securetty needs to explicitly document that without /etc/securetty it returns PAM_SUCCESS.
I think the related comments in the relevant pam files should also mention that if the entries are kept even commented out.
If pam_securetty is removed or /etc/securetty is removed it would need to be reviewed by Arch Security and have a news announcement as it is relaxing a security constraint.
Comment by tinywrkb (tinywrkb) - Saturday, 29 May 2021, 16:28 GMT
I opened a bug report for testssl.sh about backporting the hostname dependency removal to the stable branch: https://github.com/drwetter/testssl.sh/issues/1897
Comment by Geert Hendrickx (ghen) - Tuesday, 08 June 2021, 07:52 GMT
testssl.sh was already done (but not released) see https://github.com/drwetter/testssl.sh/pull/1887 and https://github.com/drwetter/testssl.sh/pull/1707

I also submitted patches to replace `hostname` with `uname -n` to dovecot, openssh, nginx, mariadb, xorg-xinit, abcde and several others, but not the ones mentioned here.

For the remaining ones:
* cvs is probably the exception that needs rsh, not hostname, but it's optional (and replaced by ssh in practice), so inetutils can be moved to optdepends there, or just dropped.
* posix-user-portability doesn't "need" inetutils since none of those tools are defined by POSIX? Is this metapackage still useful at all?
* metasploit probably uses things like rsh or talk in some of the exploit/test scripts it ships by default, but certainly not in the core.
* I haven't looked at the other ones.
Comment by loqs (loqs) - Tuesday, 08 June 2021, 08:19 GMT
talk is defined by posix [1]

metasploit uses hostname including one use of `hostname -i`. That use of `hostname -i` is packaged in opt/metasploit/docker/msfconsole.rc
pcp uses hostname including `hostname -f`. Although all the run time uses I think can be switched to `uname -n`.
rabbit-mq uses hostname including comparing hostname to hostname -s to see if the hostname is long. Although I think with changing the .install it could be changed to a makedepends.
x2goserver uses hostname see patches a few posts up if you want to try upstreaming them.
archboot uses telnet, telnetd, dnsdomainname, hostname.

I was looking at those to try and clear as many run time depends of inetutils as possible.

[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/talk.html

Loading...