Arch Linux

You can fix this by removing `/ect/securetty` from the container itself. Still the question persists if `securetty` is still needed nowadays.

Also see this comment by Lennart: https://github.com/systemd/systemd/issues/13532#issuecomment-539511591

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.

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

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.

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.

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.

@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.

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.

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?

> 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).

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.

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

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.

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

Does util-linux supplying /etc/pam.d/remote which would have the same contents as the current /etc/pamd.d/login which would then drop pam_securetty.so solve the issue?
telnetd uses login -h which uses the pam service /etc/pam.d/remote. login without -h uses /etc/pam.d/login and is intended only for local connections.
Edit:
remote should have system-local-login references changed to system-remote-login

More discussion and comprehensive explanation by seth https://bbs.archlinux.org/viewtopic.php?pid=2063758#p2063758
Edit2:
Attached diff of proposed changes

This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.

Updated PKGBUILD.diff for util-linux 2.39.1-1 and switch to git.

Removed the (already commented) securetty entry from sshd's PAM integration in https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/commit/25baf3ca2843088579efeba39f6dd1a532989324

The use of `pam_securetty.so` has been removed from /etc/pam.d/login, and the new PAM config /etc/pam.d/remote has been introduced for util-linux in https://gitlab.archlinux.org/archlinux/packaging/packages/util-linux/-/commit/6dd78c24cab7f0166ae324b1a8cd0ac7ebd18d8f