>Without /etc/securetty pam_securetty would just fall through.

Well if that is indeed the case, go for it. Except that that does not seem documented anywhere in securetty(5) or pam_securetty(8) that an empty /etc/securetty is special.

I just verified that it works in that obscure way:

1) Return to /etc/pam/login
auth	 [user_unknown=ignore success=ok ignore=ignore auth_err=die default=bad]	pam_securetty.so

2) Try login on /dev/tty1

/etc/securetty does not exist:
Allowed

/etc/securetty is empty:
Not allowed.

/etc/securetty contains tty1:
Allowed.


And yes, it seems to be undocumented.

There is only a very obscure part of util-linux documentation that mentions that:
util-linux-2.29.2/Documentation/poeigl.txt

"If /etc/securetty is present it defines which tty's that root can login on."

This file is even not part of the binary rpm package documentation.

I have created https://build.opensuse.org/request/show/807996.

https://openqa.opensuse.org/tests/1291924#

With this util-linux change staged, login over serial console is denied

Jun 07 11:55:47.445060 localhost login[2326]: pam_securetty(login:auth): access denied: tty 'hvc0' is not secure !
Jun 07 11:55:47.448114 localhost login[2326]: FAILED LOGIN 1 FROM hvc0 FOR root, Authentication failure

That only works if pam at the same time stops shipping a securetty file of course.

(In reply to Stanislav Brabec from comment #2)
> /etc/securetty does not exist:
> Allowed

then I suspect /usr/etc/securetty was used

pam_securetty has no passthrough. If there is no securetty file, pam_securetty reports an error and denies login.

That it works is because of the complicated entry, which ignores some errors. This, on the other side, has the bad side effect, that it can happen that people can login even if pam_securetty refuses login!

So please revert this change. If somebody wants to change the securetty handling, he should change it correctly upstream in pam_securetty and not break everything.

With pam not shipping "securetty" all current documentation and changes to other PAM configuration files will stop working and refuse to let root login.

The pam_securetty code:
    ttyfile = fopen(securettyfile,"r");
    if (ttyfile == NULL) { /* Check that we opened it successfully */
        pam_syslog(pamh, LOG_ERR, "Error opening %s: %m", securettyfile);
        return PAM_SERVICE_ERR;
    }


If there is no securetty file, no checks will be done. So if you don't want securetty checks, don't mess around with defaults and the securetty file, don't add the pam_securetty file.

That is not the correct code path. First the stat() fails and returns success and that is intentional according to the code documentation:
https://github.com/linux-pam/linux-pam/blob/9e5bea9e146dee574796259ca464ad2435be3590/modules/pam_securetty/pam_securetty.c#L110

No special config needed. I wouldn't have hinted that without looking at the code first.

Anyways the whole point of this report was concerns about the upgrade case that just removes pam_securetty. Ie disabling a security feature without notice. Customers who actually modified /etc/securetty probably never noticed that change. Now three years of ignoring the report later that's a bit moot anyways.

Some more thoughts.

>pam_securetty was removed from /etc/pam.d/login with the argument that remote logins use /etc/pam.d/remote anyways. However, when using a serial line with getty that is usually not the case and I think the original use case for pam_securetty.

It depends what is connected to the serial port. I would postulate that connecting a modem/telephone network in 2020/2021 is much more of a niche than having a serial console.

Ideally, whether or not a tty is secure should depend on whether it is a console. Thankfully, systemd "knows" about that. I wonder if it's time to spruce up pam_securetty and just test for whether a getty@%I.service is enabled.