Bug 798939

Summary: pam_gnome_keyring prevents "choose password at next login" and "login without password" from working
Product: [openSUSE] openSUSE 12.2 Reporter: Michael Catanzaro <mcatanzaro>
Component: BasesystemAssignee: E-mail List <gnome-bugs>
Status: RESOLVED DUPLICATE QA Contact: E-mail List <qa-bugs>
Severity: Major    
Priority: P5 - None CC: kukuk, vuntz
Version: Final   
Target Milestone: ---   
Hardware: x86-64   
OS: openSUSE 12.2   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Michael Catanzaro 2013-01-17 03:27:42 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.22+ (KHTML, like Gecko) Chromium/17.0.963.56 Chrome/17.0.963.56 Safari/535.22+ SUSE/12.2 (3.4.2) Epiphany/3.4.2

There's a discussion on this at https://bugzilla.novell.com/show_bug.cgi?id=779408, starting at Comment 14

We basically concluded that our PAM configuration is fairly broken, but none of us know what to do about it.  =/

Reproducible: Always
Comment 1 Thorsten Kukuk 2013-01-17 06:36:05 UTC
No, our configuration works exactly as designed and you are mixing two things:

authentication and changing the password.

The first one is independent of the second one. Fedora seems to allow to login with an empty password, we don't do that for security reasons. This was a strategic distribution decission.

But to set the password on the first login, you need to allow login with empty password. Between, setting password only on the first login is really dangerous, since everybody can login with that account and set his own password.

About pam_gnome_keyring.so: This is coming from the GNOME people, not from PAM maintainers. Don't use GNOME and that problem is solved, too. Or ask the GNOME people to find a better solution.
Comment 2 Thorsten Kukuk 2013-01-17 06:36:49 UTC
Adjust subject, this is a pam_gnome_keyring only problem.
Comment 3 Michael Catanzaro 2013-01-17 21:54:26 UTC
Hm, I didn't realize we didn't support empty passwords. Well that's a good reason for them to be broken!  I guess if we don't allow login without password, then the presence of a login without password option is itself a problem, and there's no way "choose password at next login" can ever work.

I don't think GNOME is going to change anything since, as you said, there's no way it can be made to work without accepting empty passwords, which is a feature of the GNOME desktop. So we need to support it or manually remove it.  I guess our two choices are:

* Have GDM simply ignore the global PAM settings
* Remove "login without password" and "choose password on next login"

The first seems wrong, the second requires patching gnome-control-center forever. Am I missing any options; Vincent, which is best?  

Thorsten, can you explain clearly what if anything is wrong with pam_gnome_keyring?  My understanding of the problem is that pam_unix2 fails in auth because it does not have nullok; this seems unrelated to gnome_keyring?
Comment 4 Vincent Untz 2013-01-18 07:38:43 UTC
(In reply to comment #2)
> Adjust subject, this is a pam_gnome_keyring only problem.

This has nothing to do with pam_gnome_keyring :-) The issue here is that accountsservice (and the UI in gnome-control-center that exposes features from accountsservice) can let people choose options wrt password management, including "login without password" and "choose password on next login".

This doesn't work by using pam_gnome_keyring, but by calling "passwd -d -- $user" (and "chage -d 0 -- $user"), so that's the standard tools.

Now, if we don't want to support this in openSUSE, that's features we should disable (both in accountsservice and in the UI).
Comment 5 Thorsten Kukuk 2013-01-18 08:49:38 UTC
(In reply to comment #4)
> (In reply to comment #2)
> > Adjust subject, this is a pam_gnome_keyring only problem.
> 
> This has nothing to do with pam_gnome_keyring :-) The issue here is that
> accountsservice (and the UI in gnome-control-center that exposes features from
> accountsservice) can let people choose options wrt password management,
> including "login without password" and "choose password on next login".

"login without password" is not an accountservice from the base system.
But if you don't use pam_gnome_keyring, it is possible to enable this
feature by calling "pam-config -a --nullok".
 
> This doesn't work by using pam_gnome_keyring, but by calling "passwd -d --
> $user" (and "chage -d 0 -- $user"), so that's the standard tools.

GNOME bug. Your conclusion/expectation is wrong. Calling "passwd -d $user" does not allow you to login the next time without password, it only deletes the password of the user.
And the second part, changing the password at next login, is working if you enter the old one first and don't delete them.

> Now, if we don't want to support this in openSUSE, that's features we should
> disable (both in accountsservice and in the UI).

It's not a question if we want to support this (we do if you don't use pam_gnome_keyring and calls "pam-config -a --nullok"), it's a matter of if we want to allow an insecure system by default where everybody can login without password.
And the decission was, that we don't want to have an insecure system by default.
Comment 6 Vincent Untz 2013-01-18 08:59:02 UTC
Thorsten: there's some confusion, probably because of the accountsservice name. accountsservice is a package providing a dbus service. It's the one calling "passwd -d", it's not GNOME. This is really completely unrelated to pam_gnome_keyring.
Comment 7 Thorsten Kukuk 2013-01-18 10:05:38 UTC
Ok, then the two bugs are:

accountservice that it calls "passwd -d" for "login without password". That's bogus. It should be called "Delete current password". But this doesn't make sense, too.

pam_gnome_keyring: integration into pam-config/pam stack was done in a way, that it breaks login without password if you call "pam-config -a --nullok".
Comment 8 Michael Calmer 2013-01-18 16:34:23 UTC
I re-assign it to some gnome maintainers list.
Comment 9 Michael Catanzaro 2013-01-25 20:59:00 UTC
We basically have two bugs for this issue now, let's keep the discussion in one place.

*** This bug has been marked as a duplicate of bug 779408 ***