[SOLVED] - Fix for Errors - Couldn't open /etc/securetty: No such file or directory

[64bitguy]

Since around 2012 there have been discussions about removing the function that is responsible for these errors spamming your error logs.

For example, See: https://bugs.debian.org/cgi-bin/bugrepo ... =674857#25

In a nutshell, this entire function is pointless unless you are managing a system over a 300 baud modem in the basement at MIT as it relates to security of users logging in as root over serial ports in a time before sudo and su and well.. SSH for that matter, and essentially of methodologies used on Unix/Linux systems of more than 20-years ago.

To address this, the people responsible began removing "pieces". I say this because somewhere around version 18 (I'm not really sure where) the dependencies started disappearing (namely, that /etc/securetty).

Now you can go on and allow your error logs to get populated with countless entries about this pointless issue, or you can apply the following fix and put an end all of that.

The choice is yours:

Fix: Remove nullock_secure from pam.
For historical reference, I just commented out the original auth line (with nullok_secure) and copy/pasted it into a new auth line just below it without the nullok_secure option.

Sudo edit /etc/pam.d/common-auth
Change:

Code: Select all

#auth	[success=1 default=ignore]	pam_unix.so nullok_secure
auth	[success=1 default=ignore]	pam_unix.so

Reboot and this problem goes away.

For example, your error logs will no longer fill up with this error every time your screen saver kicks in:
Sender: cinnamon-screen
pam_unix(cinnamon-screensaver:auth): Couldn't open /etc/securetty: No such file or directory

Nor:
Sender: sudo
pam_unix(cinnamon-screensaver:auth): Couldn't open /etc/securetty: No such file or directory

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

[Pjotr]

Interesting, but although I do have that line in /etc/pam.d/common-auth, I don't have that error in my logs.... Mint 20 Cinnamon.

[64bitguy]

If you have updated your Operating System (Versus installing clean), chances are excellent that you actually have the file in question left over from your previous version in which case you won't get the errors. I could have just as easily copied the file from snap or from a previous Mint/Ubuntu version and pasted into the destination directory to resolve the issue; but instead I chose to eliminate the function all together instead.

Either way will work.

[Pjotr]

If you have updated your Operating System (Versus installing clean), chances are excellent that you actually have the file in question left over from your previous version in which case you won't get the errors.

I always do a fresh clean installation when "jumping" to a new Mint series.... So I don't have /etc/securetty.

[64bitguy]

Well... All I can say is be grateful that this one isn't filling up your error logs.

I found it pretty damn annoying (and it is widespread).

Folks using snap probably don't see it either since the dependency comes down (to a different snap target location) which is what started some of the discourse on the Ubuntu side of the family on this subject too with Unity and the variable of using GDM/LightDM etc... on KDE, Gnome, Cinnamon, etc... and other desktop flavors). If you follow the errors forks on the provided link, you can read about it (and the rather uncomfortable discourse). I'm using Cinnamon; but as always, "Your Mileage May Vary".

[Pjotr]

There might be cases in which it does occur, of course. My system isn't exactly vanilla....

However that may be, the most cautious approach is probably to simply create /etc/securetty, like you already mentioned. Then you can be 100 % sure that you don't disrupt anything (ruling out all potential side effects).

[64bitguy]

Well.. that's where things get complicated depending on the additional options you employ.

Recreating the file from an 18.x build (from what I read) does eliminate the dependency issue; however, it doesn't necessary fix the overall issue in that in addition to it existing as a function and relying on the data within that file, the name alteration brought on a whole new set of problems with systemd and snap which is why I chose the option of simply eliminating the option altogether rather than running into other issues down the road relative to it existing in an "altered state".

Some of the language used by developers regarding snap alterations and distro's going from secure_nullok to nullok_secure (or two or three other different names, depending on distribution and version) were... well... let's just say, "colorful" and there seemed to be significant indications at Ubuntu that they would really like to see the entire function go the way of the dodo, hence the first step of eliminating the file; but yet strangely leaving the call. There doesn't seem to be much explanation for that at this point and the bug reports are simply being foreground ignored.

My concern with pulling the file in and posting it in here would be a target misalignment that would screw the pooch of the build. My thought being that what works for me today, might not work for someone else on any given day of the week if they have already made a system modification that would change the order and definitions of the data in that file. If you read the examples of where people did that, there were a couple of cases where that happened.... hence my decision to lean forward a tad and go with what appears to be the direction that the distro is headed in rather than identifying (posting) a fix, that might not be a fix. I don't want to introduce problems and would shy away from bug resolutions that might do that.

Of course users are welcome to follow the link I provided to the bug reports, find the file in question, recreate it under the assumption that doing so may or may not be a fix; but with the caveat of understanding that they are actually always going to be running that function.

Or they can choose to implement the fix in the above manner and eliminate that function entirely as it appears both the developers and Ubuntu are headed in the direction of doing anyway.

I guess this is another "Let the user decide which way they want to go" to eliminate the errors situation.

[miguelnixon]

2021-10-17 Mint 20 XFCE
I tried this and it prevented me from logging in at all: it didn't prompt for a password.
I had to boot off flashdisk and restore the
auth [success=1 default=ignore] pam_unix.so nullok_secure
So Caveat emptor!
Make sure you have a bootable repair disk, and perhaps rather just create the /etc/securetty folder as previously suggested.
My installation is a from-scratch Mint 20 XFCE, and the reason I tried this was because after a MariaDB update I couldn't start the Mysql server.
Turns out I had somehow corrupted the mysql 50-server.cnf file!