Hardy, reseting password before first login does not work through GDM

thank you for your bug report, could you explain what those random changes are supposed to do and why that should allow to log in without authentification?

Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!.

Hi Seb,

I was just doing some experimentation on a question I was asked about the shadow file. Why do you call these 'random' changes? I am only trying to understand why the instructions found here (2nd post) does not seem to work.

http://www.linuxforums.org/forum/misc/26641-how-make-passwd-accept-blank-passwords.html

I'll be converting this to a question since it's obviously not a bug. I think I'm just not understanding something.

Converted bug to question.

I had a discussion with some colleagues, and it was explained to me that this is an old UNIX hack which is not to be used anymore. The correct method to do this is to boot in recovery mode, drop to root shell and use the passwd command. The reason why this works through login (through a tty for example) but not when logging in through GDM is that GDM (or the library it depends on) was written to not allow logins for empty passwords. Even if the user was to have a null password, there would be a hash for it in /etc/shadow. Apparently this does not hold true for login (through a virtual terminal). This explains my particular experience. Feel free to discuss this with me if you can provide more technical details.

I've just been playing around with removing the password for the user account I set up for visitors, and have learned a bit more about how Ubuntu deals with blank passwords.

There's a "nullok_secure" option on one line in /etc/pam.d/common-auth, and this allows null-password logins from ttys listed in /etc/securetty. However, the tty value that PAM sees during a login from GDM looks like an X display name: :0 for the first user to log in, :20 for the first switched user, :0.0 for the first user's screen saver and so on. These values show up in the /var/log/auth.log lines that report failed logons.

There are a few ways to change this. One way that worked when I tried it was adding the following lines at the bottom of /etc/securetty:

# X sessions
:0
:0.0
:20
:20.0
:21
:21.0
:22
:22.0
:23
:23.0
:24
:24.0

I didn't like that much though, because I suspect there's nothing in particular stopping those X display values from being handed out to remote X sessions. My next try was to leave /etc/securetty alone and run the following commands instead:

$ cd /etc/pam.d
$ sudo cp common-auth common-auth-loose
$ sudo sed -i s/nullok_secure/nullok/ common-auth-loose
$ sudo sed -i s/common-auth/common-auth-loose/ gdm gnome-screensaver

This creates a loose version of /etc/pam.d/common-auth that has a nullok option where the standard one has nullok_secure, and then modifies /etc/pam.d/gdm and /etc/pam.d/gnome-screensaver to use the loose version instead of the standard one. It seems to me that this should still be acceptably secure for boxes not running XDMCP servers.

Since reading a bit more about the format of X display names, I've gone back to doing this by modifying /etc/securetty as above and leaving /etc/pam.d alone. X display names with no host specifier belong to X servers running on localhost, and it seems to me that they should therefore be treated the same way as /dev/ttyX.