users with no password can't log in with gdm

Confirmed in gdm 2.18.0-0ubuntu4.

/var/log/auth.log provides insight. I tested this with a user account named peter. Results below on attempted GDM login...

Apr 9 23:59:04 khermans-laptop gdm[9757]: (pam_securetty) access denied: tty ':20' is not secure !
Apr 9 23:59:04 khermans-laptop gdm[9757]: (pam_securetty) access denied: tty ':20' is not secure !
Apr 9 23:59:04 khermans-laptop gdm[9757]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=:20 ruser= rhost= user=peter

that's know upstream: http://bugzilla.gnome.org/show_bug.cgi?id=414862

Isn't this a PAM bug?

I get the same result as Kristian Erik Hermansen above, namely that login is rejected by pam_securetty. However, I do not quite see why pam_securetty should be run.

> grep -r pam_securetty /etc/pam.d
/etc/pam.d/login:auth requisite pam_securetty.so

So, if I am not mistaken, pam_securetty should only be run for the "login" service, not for gdm.
Also, /usr/share/doc/libpam-doc/html/pam-6.html#ss6.23 states for the pam_securetty module: "Provides standard Unix securetty checking, which causes authentication for root to fail unless PAM_TTY is set to a string listed in the /etc/securetty file. For all other users, it succeeds."

So pam_securetty should not be run at all, and it should certainly not fail.

This is untested, but the problem might be this:

pam-0.79/Linux-PAM/modules/pam_unix/support.c: _unix_blankpasswd contains the following:

 if ((retval == 1) && on(UNIX_NULLOK_SECURE, ctrl)) {
  int retval2;
  const char *uttyname;
  retval2 = pam_get_item(pamh, PAM_TTY, (const void **)&uttyname);
  if (retval2 != PAM_SUCCESS || uttyname == NULL)
   return 0;

  if (_pammodutil_tty_secure(uttyname) != PAM_SUCCESS)
   return 0;
 }

It appears that the tty is always checked if the password is blank.
Can anybody confirm that this is, in fact, the problem? Why is this check performed?

It is not gdm issue, you can easily fix it by edit /etc/pam.d/gdm

replace this line:
@include common-auth
with
auth required pam_unix.so nullok

Because common-auth will check if the login user has a tty when empty password is provide.
But you can not get a tty from gdm login window.

by the way, you'd better also edit /etc/pam.d/xscreensaver, or you could not unlock the window if screensaver started.

I haven't tested Zealot's fix yet, but it looks promising.

The man page for pam_unix has the following to say about the nullok_secure option that is used in /etc/pam.d/common-auth:
The default action of this module is to not permit the user access to a service if their official password is blank. The nullok_secure argument overrides this default and allows any user with a blank password to access the service as long as the value of PAM_TTY is set to one of the values found in /etc/securetty.

Thus, the behavior of the module is as documented; it's a feature, not a bug! =)

So, the only possible fix would be changing nullok_secure to nullok as per Zealot's fix above (or globally in /etc/pam.d/common-auth). I do not know enough about the security implications of such a change to tell whether it would be a good idea in a default install, so I am leaving this open for now.

The other way to fix this, rather than disabling nullok_secure (which isn't a good idea as a default), would be to add your X console to /etc/securetty. Can someone test and confirm that this works?

I'm not sure whether doing that by default would be a good idea, either, from a security standpoint. I think we would want to be able to distinguish local X sessions from XDMCP sessions for such a change, and I'm not sure how that's possible. Sebastien, perhaps you have some thoughts on this?

the xdmcp browser and standard login greeter are different interface so it would probably be possible to special cases non password local logins if somebody really wants to work on this nonsecure option

On Wed, Jul 30, 2008 at 10:13:01PM -0000, Sebastien Bacher wrote:
> the xdmcp browser and standard login greeter are different interface so
> it would probably be possible to special cases non password local logins
> if somebody really wants to work on this nonsecure option

Do xdmcp and the standard greeter declare separate PAM service names?
Otherwise it's still not practical to do this by default without introducing
a security hole, because unless the two can be distinguished by "tty" (i.e.,
X display) values, the PAM behavior is going to be either insecure, or block
out this use case.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

> Do xdmcp and the standard greeter declare separate PAM service names?

not that I know no but I'm not a pam expert and you might want to look at the code to make sure that's not the case

On Thu, Jul 31, 2008 at 08:34:43AM -0000, Sebastien Bacher wrote:
> > Do xdmcp and the standard greeter declare separate PAM service names?

> not that I know no but I'm not a pam expert and you might want to look
> at the code to make sure that's not the case

The gdm code does the following to decide what service name to use:

        pam_stack = gdm_daemon_config_get_value_string_per_display (GDM_KEY_PAM_STACK,
                (char *)d->name);

So it looks up the service name on a per-display basis. If the mapping of
display names for xdmcp is normally static, it's still simpler to add the
"trusted" local displays to /etc/securetty instead of munging the PAM
config, I think.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

My Hardy desktop box has five user accounts, one of which (visitor) has no password. I can confirm that appending the following to /etc/securetty enables visitor to log in via GDM and successfully unlock gnome-screensaver and switch users.

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

Do display names in this form always belong to local X servers? If so, including a bunch of them in /etc/securetty is probably the Right Thing.

I can also confirm that leaving /etc/securetty unmolested and doing the following instead gets the job done too:

$ 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

Is this all kinds of insecure as it stands, or only if I turn on XDMCP?

I don't know if the display names always belong to local X servers; answering that question would go a long way to help resolve this bug.

It's definitely only insecure if you turn on XDMCP, though, so for your local use that should be fine.

On Wed, Mar 4, 2009 at 10:25 AM, Steve Langasek
<email address hidden> wrote:
> I don't know if the display names always belong to local X servers;
> answering that question would go a long way to help resolve this bug.

OK. I just tested this by turning on XDMCP on the desktop box
(192.168.119.2), and logging in from my laptop (192.168.119.5). From
the laptop, attempting to log in as visitor fails, and when I
subsequently log in as stephen and check /var/log/auth.log, I see that
the failed visitor login has caused

access denied: tty '192.168.119.5:3' is not secure !

So it looks like the names that PAM sees will in fact have a prepended
hostname if they are X displays running remote. On that basis, I'm
perfectly happy just to tack

# Local X displays
:0
:0.0
:1
:1.0
:2
:2.0
:3
:3.0
...
:63
:63.0

onto the end of /etc/securetty for my own use, and can see no real
reason why this shouldn't be done as a distro default.

Looks to me like the routines that parse /etc/securetty might benefit
from some kind of wildcard support, though. That would make things
much easier for anybody who actually wanted to turn on some
password-free logins via a room full of thin clients. I can see a use
for this in a classroom or public library, for example.

I've assigned this bug to shadow (login) packages, because according to latest comments from Flabdablet and <email address hidden> the way to solve password-less local login bug by adding lines bellow to /etc/shadow is correct:

# Local X displays
:0
:0.0
:1
:1.0
:2
:2.0
:3
:3.0
...
:63
:63.0

2009/5/9 Mantas Kriaučiūnas <email address hidden>:
> I've assigned this bug to shadow (login) packages, because according to
> latest comments from Flabdablet and <email address hidden> the
> way to solve password-less local login bug by adding lines bellow to
> /etc/shadow is correct

They need to be added to /etc/securetty, not /etc/shadow.

On Sun, May 10, 2009 at 05:32:33AM -0000, Flabdablet wrote:
> 2009/5/9 Mantas Kriaučiūnas <email address hidden>:
> > way to solve password-less local login bug by adding lines bellow to
> > /etc/shadow is correct
>
> They need to be added to /etc/securetty, not /etc/shadow.

Yes, to /etc/securetty - this file is in login package, which builds from shadow sources - I wanted to write /etc/securetty but by mistake wrote /etc/shadow ;)

--
Labanaktis/Good luck,
Mantas Kriaučiūnas Jabber ID: <email address hidden> GPG ID: 43535BD5
Public organization "Open Source for Lithuania" - www.akl.lt
Naudok Baltix GNU/Linux sistemą savo kompiuteryje - http://baltix.lt

I will add these lines to /etc/securetty in the next Debian package.

Why did you included the displays from 0 to 63? (Is 63 the maximum, or is it just meant to be mostly complete?)
If 63 is not the maximum, I would prefer to reduce the number of displays to a more reallistic value (i.e. I do not expect so many displays on systems were empty passwords are allowed), but maybe also add support for systems with multiple heads (i.e. also support :0.1).

I submitted http://bugs.debian.org/528015 to update the documentation or securetty, since this usage is quite different from what is currently documented.

What status should pam and shadow be? Is this a bug in those packages? If so, please set these as Triaged too, and if not mark them Invalid - for now I shall mark these as Incomplete. Thank you guys.

that's not an appropriate use of the 'incomplete' status.

I realise that, but I was always told to set bugs to Incomplete status if asking for information, but it does look messy as "new" :) Should these be Confirmed then?

The 'incomplete' status is meant to indicate that more information is needed from the bug submitter. You appear to be asking for information from the developers...

It's already been acknowledged by one of the shadow developers as a bug in that package. I'm still considering whether we should also treat this as a bug in pam for not having a sensible wildcard format for /etc/securetty.

Agreed. Is this OK to mark shadow as Confirmed? I shall leave this in your more-than-capable hands then Steve, and sorry for the confusion. Thank you :)

See bug 393854 for a related approach of the problem of password-less logins. It suggests using accounts that actually have a password, but not to check it when logging with GDM. While this may not suit all cases described here, that can solve many of them.

BTW, the upstream bug in GDM has moved towards the solution I have described in my previous comment. As stated in this report, the present problem is in Debian/Ubuntu, not GDM.

there is no reason to no keep the upstream bug referenced there

...except that the upstream bug linked here does not deal with the present problem at all, and never has. It is now marked as Fix Released since I committed patches for that, but these patches are not related to our problem which *is only in Ubuntu packaging*. Upstream has nothing to do with this at all.

could you explain what is the packaging issue there then and how it's different from the other bug and the GNOME change you did? adding statements without explanations of the issue is not really constructive there

Sorry, I thought I had been explicit enough.

The present bug deals with users with an empty password (using 'passwd -d'), while bug 393854 is about users actually having a password, but GDM not checking it to log in. In the present bug, GDM is handling the problem fine, we only need our PAM config files allow for empty password on graphical ttys: for now, they are not considered as secure ttys, while they should (above discussion). In the other bug, we need our PAM config file for GDM to allow members of the nopasswdlogin group to log in without any further authentication.

So nothing related in the way we should fix those, while they target related use cases. Hope this helps.

the new comment clarify some things but the issue seems rather a policy decision rather than a packaging bug as you suggested

the issue is fixed upstream now

I tried the method by adding a user: useradd test and then from the switch user I went into test and was able to login without a password. This problem doesn't exist in the later kernels. Please update your kernel which will solve your problem and thanks for reporting this bug...

This bug has nothing to do with kernels. The pam task is still open for the reason given in <https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/104957/comments/24>. Do not touch the status of this task....

Please, be rigorous when performing tests. This bug is about logging in from GDM, not form the fast-user-switch-applet. They can perfectly use different policy files in /etc/pam.d, so they need to be treated separately. And i don't see how this could be related to your kernel version (securettys?).

I'm reopening this bug waiting for somebody to test this in Karmic. And BTW, as I said, the upstream bug has nothing to do with the current problem, so I'm removing the link.

Sorrry :(

Well in that case, I'm marking the gdm Ubuntu task as invalid. The Debian shadow maintainer has agreed that /etc/securetty should mark these X displays as trusted. This hasn't entirely been implemented yet since fusa jumps straight to :20 as its next display number and /etc/securetty only goes up to :3 currently, so this still needs to be implemented (either by supporting wildcards in pam or by listing out all the displays in /etc/securetty), but in either case no code can or should be changed in gdm for this.

I agree with Milan Bouchet-Valat, this has nothing to do with the upstream bug, and I did the tests over again and (my fault) using GDM the login fails in Karamic Alpha 3 (daily build). Bug 393854 offer a solution So I don't see a reason not to mark this bug confirmed. Please take acitons as necessary.....

Thanks,
Vikram

Thanks for agreeing with me on this case

On Wed, 2009-08-19 at 20:14 +0000, Steve Langasek wrote:
> Well in that case, I'm marking the gdm Ubuntu task as invalid. The
> Debian shadow maintainer has agreed that /etc/securetty should mark
> these X displays as trusted. This hasn't entirely been implemented yet
> since fusa jumps straight to :20 as its next display number and
> /etc/securetty only goes up to :3 currently, so this still needs to be
> implemented (either by supporting wildcards in pam or by listing out all
> the displays in /etc/securetty), but in either case no code can or
> should be changed in gdm for this.
>
> ** Changed in: gdm (Ubuntu)
> Status: Fix Committed => Invalid
>
> ** Changed in: pam (Ubuntu)
> Importance: Undecided => Medium
>

Nicolas François wrote on 2009-05-10:

Why did you included the displays from 0 to 63? (Is 63 the maximum, or is it just meant to be mostly complete?)

I had no idea about maximums - I was just following the existing pattern for ttyNN and vc/NN. But from what Steve Langasek wrote on 2009-08-19, the instinct seems sound :-)

In contrast to Bug #393854, this bug is fixed in Karmic Koala. Just click on the username in gdm to login. Great! There's only a GUI to remove the password in users-admin missing.

Users with no password can login with GDM without any problems in Karmic Koala.

Any idea about the status of this in shadow and pam? Is this fixed because GDM is now considered as a secured tty, as it should?

This bug is not fixed in karmic, for the reasons stated in https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/104957/comments/38

why should it be a bug instead of a security-feature?

for me its the same like "root is not able to login into gdm". So what is the reason to have this bug open?

Also there is the guest-session

and if it is needede (e.g. for kiosk-mode) this should not be the default in ubuntu. if someone wants login without password he should edit the needed configs in my opinion

On 2 November 2011 01:41, Michael Basse <email address hidden> wrote:
> why should it be a bug instead of a security-feature?

Because the policy defined in /etc/securetty for local graphical
terminals is inconsistent with the policy defined there for local text
terminals, and because the lack of wildcard support in the code that
parses /etc/securetty will continue to cause surprises for users whose
local ttys don't fit one of the device/display names defined
explicitly there.