pam_unix(sudo:auth): Couldn't open /etc/securetty: No such file or directory

Bug #1860826 reported by Seth Arnold
302
This bug affects 65 people
Affects Status Importance Assigned to Milestone
pam (Debian)
Fix Released
Unknown
pam (Ubuntu)
Low
Unassigned
Focal
Undecided
Unassigned
Groovy
Low
Unassigned

Bug Description

Hello, after upgrading to focal I found the following in my journalctl output:

Jan 24 23:07:00 millbarge sudo[32120]: pam_unix(sudo:auth): Couldn't open /etc/securetty: No such file or directory
Jan 24 23:07:01 millbarge sudo[32120]: pam_unix(sudo:auth): Couldn't open /etc/securetty: No such file or directory

The login package stopped packaging this file:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731656
and now forcibly removes the file:
https://paste.ubuntu.com/p/myh9cGWrHD/

However, the pam package's pam_unix.so module has not yet been adapted to ignore this file:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674857#25

Thanks

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: libpam-modules 1.3.1-5ubuntu4
ProcVersionSignature: Ubuntu 5.4.0-9.12-generic 5.4.3
Uname: Linux 5.4.0-9-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu15
Architecture: amd64
Date: Fri Jan 24 23:35:33 2020
ProcEnviron:
 TERM=rxvt-unicode-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: pam
UpgradeStatus: Upgraded to focal on 2020-01-24 (0 days ago)

Revision history for this message
Seth Arnold (seth-arnold) wrote :
tags: added: champagne
Revision history for this message
Sebastien Bacher (seb128) wrote :

Looks like Balint has been looking at that problem from the Debian side, assigning to him

@Balint, feel free to unassign if I got that wrong :)

Changed in pam (Ubuntu):
assignee: nobody → Balint Reczey (rbalint)
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Balint Reczey (rbalint) wrote :

@seb128 reading the referenced bug further reveals that I'm waiting for PAM maintainers' input on this.

Changed in pam (Ubuntu):
assignee: Balint Reczey (rbalint) → nobody
Changed in pam (Debian):
status: Unknown → New
tags: added: id-5ebd60b9e10a724ad7cbaffe
Revision history for this message
Joshua Peisach (itzswirlz) wrote :

I would say there is probably a missing dependency-/etc/securetty doesn't exist in Ubuntu and looks like it could be a typo.

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Joshua, it's not a typo, and not a missing dependency:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674857#25

Thanks

tags: removed: champagne
Revision history for this message
Francesco Minnocci (qwerty1214) wrote :

So is it safe for an user to just remove "nullok_secure" as suggested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931899 ?

Revision history for this message
ITEAS (info-tux-pc) wrote :

Same here after focal Update with local sudoers. With sudoers over ActiveDirectory (SSS) it is working, but all local entries are ignored @20.04.

Revision history for this message
xibbvngcey (bhfbiibii) wrote :

does it cause the lock screen to freeze during unlock?

My lock screen during unlock freezes occasionally (once every 2 weeks), and this is one of 3 logs having recent updates:
Aug 27 18:37:02 PCName gdm-password]: pam_unix(gdm-password:auth): Couldn't open /etc/securetty: No such file or directory
Aug 27 18:37:12 PCName gdm-password]: pam_unix(gdm-password:auth): Couldn't open /etc/securetty: No such file or directory
Aug 27 18:37:12 PCName gdm-password]: gkr-pam: unlocked login keyring

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 1860826] Re: pam_unix(sudo:auth): Couldn't open /etc/securetty: No such file or directory

On Thu, Aug 27, 2020 at 06:02:33PM -0000, bood wrote:
> does it cause the lock screen to freeze during unlock?

No. Please file a separate bug for your issue.

Revision history for this message
Sterling Butters (sterlingbutters) wrote :

Would this bug cause a gnome-session initialization delay? My logs have this error and technically everything "works" correctly but initialization of the user session takes > 1 min. The greeter isn't exactly fast either but definitely more tolerable. My systemd analysis looks fine too. Really hoping this bug is the issue.

Revision history for this message
Steve Langasek (vorlon) wrote :

On Tue, Sep 01, 2020 at 01:53:00AM -0000, Sterling Butters wrote:
> Would this bug cause a gnome-session initialization delay?

No, it would not. The sum totality of the impact of this bug is the extra
warning messages in the log files.

Revision history for this message
Sterling Butters (sterlingbutters) wrote :

> No, it would not. The sum totality of the impact of this bug is the extra
warning messages in the log files.

Damn...

tags: added: fr-14
Revision history for this message
Tero Gusto (tero-gusto) wrote :

I am still seeing this in Ubuntu 20.04.1:

Oct 23 17:29:10 comp gdm-password][1766]: pam_unix(gdm-password:auth): Couldn't open /etc/securetty: No such file or directory

Revision history for this message
Zach H (no.ones.there) wrote :

Hi, just to confirm that this may be a bigger issue than first anticipated - on Ubuntu Server 20.04 this is causing issues with logins via sftp/ftp. Because of this, the migration of a number of our servers has had to be halted until this bug has been completed. Copy-pasting the Securetty file could be an option, but a more permanent solution is preferred.

Revision history for this message
Steve Langasek (vorlon) wrote :

On Tue, Oct 27, 2020 at 03:49:30AM -0000, Zach H wrote:
> Hi, just to confirm that this may be a bigger issue than first
> anticipated - on Ubuntu Server 20.04 this is causing issues with logins
> via sftp/ftp.

Why do you believe your issue is caused by this bug? The only known effect
of this bug is the extraneous log entries; it is not known to cause pam
modules to return different results.

You can test this by temporarily editing /etc/pam.d/common-auth to list
'nullok' instead of 'nullok_secure'. If your problem persists, then it is
unrelated to this bug.

Revision history for this message
Glen Duncan (playaspec) wrote :

It also appears to affect cups.

# systemctl status cups.service
● cups.service - CUPS Scheduler
     Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2020-11-05 15:45:21 EST; 32min ago
TriggeredBy: ● cups.path
             ● cups.socket
       Docs: man:cupsd(8)
   Main PID: 1216169 (cupsd)
      Tasks: 3 (limit: 76795)
     Memory: 12.3M
     CGroup: /system.slice/cups.service
             ├─1216169 /usr/sbin/cupsd -l
             ├─1216235 /usr/lib/cups/notifier/dbus dbus://
             └─1216236 /usr/lib/cups/notifier/dbus dbus://

Nov 05 15:45:21 Cortex1 systemd[1]: Started CUPS Scheduler.
Nov 05 15:45:50 Cortex1 cupsd[1216169]: pam_unix(cups:auth): Couldn't open /etc/securetty: No such file or directory
Nov 05 15:45:50 Cortex1 cupsd[1216169]: pam_unix(cups:auth): Couldn't open /etc/securetty: No such file or directory
Nov 05 15:45:55 Cortex1 cupsd[1216169]: pam_unix(cups:auth): Couldn't open /etc/securetty: No such file or directory
Nov 05 15:45:55 Cortex1 cupsd[1216169]: pam_unix(cups:auth): Couldn't open /etc/securetty: No such file or directory
Nov 05 15:47:57 Cortex1 cupsd[1216169]: pam_unix(cups:auth): Couldn't open /etc/securetty: No such file or directory
Nov 05 15:47:57 Cortex1 cupsd[1216169]: pam_unix(cups:auth): Couldn't open /etc/securetty: No such file or directory
Nov 05 15:50:01 Cortex1 cupsd[1216169]: pam_unix(cups:auth): Couldn't open /etc/securetty: No such file or directory
Nov 05 15:50:01 Cortex1 cupsd[1216169]: pam_unix(cups:auth): Couldn't open /etc/securetty: No such file or directory

I created an empty file to silence the error, but I'm a bit dismayed that this file was removed without coordination with the pam project, or at least patching or configuring pam to avoid this error. Clearly this impacts more than just a deprecated telnet.

Revision history for this message
David Ward (dpward) wrote :

Despite what Launchpad is showing here, the upstream Debian bugs were fixed over a month ago:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936071#23
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674857#61

Ubuntu maintainers: please add the "Focal" series for this bug.

Revision history for this message
David Ward (dpward) wrote :

In fact the comments above explicitly say "Closes: #674857, #936071, LP: #1860826 [this bug]".

Changed in pam (Debian):
status: New → Fix Released
Revision history for this message
Robie Basak (racb) wrote :

I'm adding a Focal task as requested in #ubuntu-bugs. However, please don't take this as an endorsement for a Focal SRU. If it's just spurious log entries, I'm not sure if an SRU would be appropriate or not.

David Ward (dpward)
Changed in pam (Ubuntu Focal):
status: New → Confirmed
Revision history for this message
Bin Li (binli) wrote :

After I upgraded libpam-runtime from 1.3.1-5ubuntu4.1 to 1.3.1-5ubuntu4.2, I also met this error.

Revision history for this message
Elliott Balsley (elliottbalsley) wrote :

This also spams the vsftpd log several times per minute

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.