*** Bug 587604 has been marked as a duplicate of this bug. ***

*** Bug 592340 has been marked as a duplicate of this bug. ***

This was caused by this change:

    2009-03-03  William Jon McCann  <jmccann@redhat.com>
    
        * daemon/gdm-static-display.c (gdm_static_display_unmanage):
        Don't limit autologin to one time.  This was
        a lame attempt to try to avoid loops on failed logins.
        Should probably handle this better.

However, I don't see why you would want autologin to work later than on first start. Any reason for this?

There are some situations where the current behavior is useful.  For example, it would be useful in kiosk environments where you want each terminal to log into a specific user all the time.  This way, if the Xserver or gnome-session dies for some reason, it just restarts the session.

There are also some situations where Sun Ray software wants to start a session without authentication and without showing the login screen.  This happens, for example, when a user authenticates on one server, but their $HOME account is actually on a second server.  So after authentication on the first server, the users session is redirected to the second server.  In this case GDM is used to start the session but the GDM login GUI should not appear.  Instead it should just log in the specified user immediately.

For these sorts of environments to work, bug #591383 needs to be fixed, though I plan on working on fixing that bug soon.  Without fixing #591383 it is not possible to specify different automatic login users per-display.

So, I think it would be useful to have a configuration option that allows you to control whether automatic login works all the time, or just the first time and then switches to TimedLogin.

I appreciate the special cases, but today, most people with autologin just don't have a kiosk or a Sun Ray with special software. So there is no way any more to not be logged in any more.

I know there's the "but there's user switching" argument, but it doesn't quite work: for example, if I can never really log out of my machine, my wife would be unable to shut down the machine, since this requires admin privileges (due to ConsoleKit allowing shutdown when multiple users are logged in  only with authorization). Also, there are cases where you can't run two X servers at the same time in a sensible manner (not everyone uses intel with KMS today).

(In reply to comment #5)
> I appreciate the special cases, but today, most people with autologin just
> don't have a kiosk or a Sun Ray with special software. So there is no way any
> more to not be logged in any more.

There are hundreds of thousands of such devices deployed. They are used in the military, call centers, corporations, electronic signage, etc. etc. I think sometimes we think our own perspective represents the general case, but that's often not the case. Because we don't see something doesn't mean it doesn't exist.

A few examples of such Sun Ray use are here, if you are interested
http://www.sun.com/sunray/success.xml
These represent only a few customers who have agreed to work with Sun to have the details of their environment published. The majority use Kiosk mode. I'm sure there are plenty of other examples to be found for other non-Sun Ray applications but I'm unaware of specific citations.

> I know there's the "but there's user switching" argument, but it doesn't quite
> work: for example, if I can never really log out of my machine, my wife would
> be unable to shut down the machine, since this requires admin privileges (due
> to ConsoleKit allowing shutdown when multiple users are logged in  only with
> authorization). Also, there are cases where you can't run two X servers at the
> same time in a sensible manner (not everyone uses intel with KMS today).

Doesn't this seem like an overly constrained scenario to you? 'Your wife doesn't have administrative privs so you must log out'? If you want her to have shutdown privs, you could always give them to her rather than be forced to log out first (this is really a silly behavior in ConsoleKit IMO - why should a user get elevated privileges simply because they're the only one logged in at the moment? How does that user know there's not some important background/daemon job currently executing, some network service about to be offered, or some critical cron job execution scheduled to occur? Hopefully this is configurable)...

(In reply to comment #5)
> I appreciate the special cases, but today, most people with autologin just
> don't have a kiosk or a Sun Ray with special software. So there is no way any
> more to not be logged in any more.
> 

There is two different use cases for autologin:
1) Do a default login at boot, revert to ordinary (authenticated) login upon explicit logout. 
2) Stay logged in as an autologin user all the time. Relogin automatically when logging out. This is used for kiosk-type scenarios. (As an extra twist we may want the autologin user to change upon relogin in this case.)

Using timed login upon explicit logout is middle ground between these two, with (1) being the behavior when the timeout becomes infinite and (2) being the timeout=0 case.  FWIW I find the intermediate timed-login cases to be of little use: if I log out explicitly I want the machine to stay logged out.

To honor both requirements we need a way to configure whether autologin (or timed login) also includes automatic relogin. This would not yield the specific case of first-time autologin and subsequent timed login though, but I am not sure I see a conclusive use case for that.

> I know there's the "but there's user switching" argument, but it doesn't quite
> work: for example, if I can never really log out of my machine, my wife would
> be unable to shut down the machine, since this requires admin privileges (due
> to ConsoleKit allowing shutdown when multiple users are logged in  only with
> authorization). 

I sort of see your argument. Giving your wife shutdown privileges, as suggested by Bob, will allow shutdown when your session is still doing important stuff in the background.

But stepping back, I don't really see what your configuration is intended to achieve. If you want to make your machine accessible to your wife, then using (untimed) autologin is a somewhat contradictory configuration: your wife can't get into her login without first going through your account. And your account is completely unprotected anyhow.

Actually in the setup you describe, when your wife logs out, wouldn't she be autologged in as you and then could shutdown the box as you. (Having a password-protected screen lock together with passwordless autologin is really meaningless.) In your model, what is actually protected by authentication?

> Also, there are cases where you can't run two X servers at the
> same time in a sensible manner (not everyone uses intel with KMS today).

Huh? What specifically are you referring to? What X11 implementation supports only a single X server (on a machine you log into)? Or do you mean only a single X server on the/a console, so that you can't switch users?

> Doesn't this seem like an overly constrained scenario to you?

Not at all. I was just pointing out some random scenarios. I didn't even
mention that on many devices it's just a waste of resources/RAM to have several
sessions in parallel. But my primary point is that this current default
behaviour simply doesn't make sense to me in most situations.

> this is really a silly behavior in ConsoleKit IMO - why should a
> user get elevated privileges simply because they're the only one logged in at the moment?

Just for the very reason you mention, to avoid killing another person's work,
e. g. from an open editor or word processor, or an ongoing download.

> How does that user know there's not some important background/daemon job currently executing,

That's not really a common case on a desktop PC, since you can't rely on being
on 24/7 anyway.

> There are hundreds of thousands of such devices deployed.

Right, and there are tens of millions of desktop PCs. As I said, I appreciate
the reasons you mentioned, but I'm not a big fan of optimizing for the less
common case.

Even on a Sunray terminal, why would you log out just to immediately log back
in as the same user? That doesn't make any sense to me at all. I don't see the
purpose of an immediate autologin other than the first time the computer
starts, except for the "network chain-login" you described (but even in this
case, this configuration is more of a hack than a representative use case).

> So, I think it would be useful to have a configuration option that allows you
> to control whether automatic login works all the time, or just the first time
> and then switches to TimedLogin.

I agree. Would you accept a patch which adds this to gdm-custom.conf?

> FWIW I find the intermediate timed-login cases to be of little use: if I log out explicitly I want the machine to stay logged out.

I agree.

> In your model, what is actually protected by authentication?

My user account (in that scenario) isn't locally protected at all at boot, of course. (I don't personally use it, but given how many bug reports we get about autologin there seem to be a lot of people who do). However, it does become protected when I switch user, since then the screen locks. I guess the point of the CK question is to ensure that you don't stomp over someone else's work.

Sure, an autologin user could give shutdown privs to other users, etc., or we could just disable that priv check by CK, or whatnot (this CK issue isn't actually my primary concern; I just brought it up as one random example).

> Huh? What specifically are you referring to? What X11 implementation supports
> only a single X server (on a machine you log into)?

It's more like a driver issue. For example, until recently you could only have one hw-accelerated head with the -intel driver, and the fglrx driver still crashes on a a lot of hardware when you start a second one.

But well, I don't actually want to discuss/defend sucking drivers or weird CK behaviour. Just in terms of pure usability it is totally confusing to log out just to get logged back in right away. This is what I'd like to argue about primarily.

So, adding a configuration switch for this sounds great to me, then desktop oriented distros could set it to "only autologin at gdm start", and kiosk setups could set it to "always cycle".

I think it is good for people to talk about the different ways they use GDM, so we can reflect on the best way to make it work properly.  While I do agree that it makes sense to optimize for the most common use cases, this hopefully should not mean that we make it impossible, or overly cumbersome, for less common cases to work.  At least not without a better reason than "we are optimizing for the common use case".

Note that GDM has been enhanced (see bug #591383) so that you can specify the automatic/timed login user via a script.  This allows for per-display configuration of the user, and there is no reason a script couldn't return a different user each time you log in on the same display, if desired.  For this to work properly, though, the login should fall back to normal (non-autologin & non-timed), when the script returns an invalid username, or if the static configuration file has an invalid username.  I believe this is how GDM works today, but we should make sure not to break this behavior.  

At any rate, I think this feature does not really require any new configuration options.  In the new GDM, automatic login is already the same as timed login with a timeout of 0.  So, why don't we just make GDM autlogin always do timed login on subsequent logins, and users who want "autologin all the time" can just set the timed login delay to 0.  Wouldn't this always make it behave as if autologin were on each time?

So, some questions about how the configuration should work to support this
fallback to timed-login feature on subsequent login:

- For this to work, do I need to specify the AutomaticLogin user and the 
  TimedLogin user to the same user (or script), or do I just set the 
  AutomaticLogin user and it gets used as the TimedLogin user on subsequent 
  logins?  Seems a little ugly either way, to me.
- It seems a little odd that you would set need to set TimedLoginDelay when 
  TimedLoginEnable is false.  Should there be a separate AutomaticLoginDelay or 
  should the key name change to something like LoginDelay that doesn't imply 
  whether it is being used by Automatic or Timed login?

Created attachment 144552 [details] [review]
Do not autologin again after a logout

Here's a patch I'll use in openSUSE. It's really just about autologin (which will work only the first time), and it doesn't affect timed logins.

A few notes:

 + I'm not even sure why we're considering using timed login after a first autologin (and the patch doesn't do this). What's the rationale for such a behavior?

 + a timed login of 0s is not possible (looking at the code, a value of 10s is used in such a case)

 + if people really want autologin active all the time, then, IMHO, to avoid any confusion, it should be a specific setting.

Why not add such a configuration setting now, so the code does what your prpoosed patch does by default, but users can configure it to always autologin if they want?

It's pretty simple, just add a new configuration option to the data/gdm.schemas.in.in file, and call gdm_settings_client_get_boolean.  Refer to how GDM_KEY_DISALLOW_TCP currently works to see how to call the config functions.

(In reply to comment #12)
> Why not add such a configuration setting now, so the code does what your
> prpoosed patch does by default, but users can configure it to always autologin
> if they want?

I didn't want to add a new option in a distro patch. But if this is what we want to do upstream, sure, I'm fine with that. I can try to do it during the Boston Summit, I guess (I'm a bit short in time this week).

Does the gdm in 2.28 have the gconf setting? 
Ubuntu has reverted the upstream timed auto-login setting. So not sure if it is possible.

this is a behaviour changes between 2.20.x and latest gdm release, where a previous configuration will not give the expected behaviour for users (and will cause a pain for migration).

FYI, I'm applying Vincent patch to Mandriva gdm 2.30.x package.

*** Bug 617482 has been marked as a duplicate of this bug. ***

I'd like to get vuntz patch in now for 2.91.  if there are cries from the change in behavior we can consider adding some sort of kiosk mode option.

it's just bizarre that logout doesn't visibly log out.

Shouln’t this be closed?
It was committed as f06d3c70.

ya