[Bug 1033626] New: pam_securetty in /etc/pam.d/login or not
http://bugzilla.suse.com/show_bug.cgi?id=1033626 Bug ID: 1033626 Summary: pam_securetty in /etc/pam.d/login or not Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: sbrabec@suse.com Reporter: lnussel@suse.com QA Contact: qa-bugs@suse.de CC: jengelh@inai.de Found By: --- Blocker: --- 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. So in order to keep existing configs working and make use cases like machinectl work at the same time I'd suggest to put pam_securetty back into the config file but not ship an /etc/securetty by default anymore. Without /etc/securetty pam_securetty would just fall through. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1033626 http://bugzilla.suse.com/show_bug.cgi?id=1033626#c1 --- Comment #1 from Jan Engelhardt <jengelh@inai.de> ---
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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1033626 http://bugzilla.suse.com/show_bug.cgi?id=1033626#c2 Stanislav Brabec <sbrabec@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED --- Comment #2 from Stanislav Brabec <sbrabec@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1033626 Marcus Meissner <meissner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |meissner@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1033626 http://bugzilla.suse.com/show_bug.cgi?id=1033626#c3 Marketa Calabkova <mcalabkova@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mcalabkova@suse.com Assignee|sbrabec@suse.com |qa-bugs@suse.de --- Comment #3 from Marketa Calabkova <mcalabkova@suse.com> --- I have created https://build.opensuse.org/request/show/807996. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1033626 http://bugzilla.suse.com/show_bug.cgi?id=1033626#c5 --- Comment #5 from Ludwig Nussel <lnussel@suse.com> --- That only works if pam at the same time stops shipping a securetty file of course. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1033626 http://bugzilla.suse.com/show_bug.cgi?id=1033626#c7 --- Comment #7 from Thorsten Kukuk <kukuk@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1033626 http://bugzilla.suse.com/show_bug.cgi?id=1033626#c8 --- Comment #8 from Thorsten Kukuk <kukuk@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1033626 Thorsten Kukuk <kukuk@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kukuk@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1033626 http://bugzilla.suse.com/show_bug.cgi?id=1033626#c9 --- Comment #9 from Ludwig Nussel <lnussel@suse.com> --- 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/9e5bea9e146dee574796259ca464ad24... 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. -- You are receiving this mail because: You are on the CC list for the bug.
participants (2)
-
bugzilla_noreply＠novell.com -
bugzilla_noreply＠suse.com