Bug 250147 - add optional support for gnome-keyring to passwd pam stack
add optional support for gnome-keyring to passwd pam stack
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gnome-keyring (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Tomáš Bžatek
Fedora Extras Quality Assurance
:
: 472882 (view as bug list)
Depends On: 441225 441226
Blocks: F8Target 356931
  Show dependency treegraph
 
Reported: 2007-07-30 14:11 EDT by Matthias Clasen
Modified: 2015-03-03 17:31 EST (History)
21 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 12:33:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
authconfig patch for skipping to end on success (5.84 KB, patch)
2007-10-05 08:10 EDT, Alexander Larsson
no flags Details | Diff

  None (edit)
Description Matthias Clasen 2007-07-30 14:11:24 EDT
gnome-keyring now ships a pam module that (among other things) can update the 
password of keyrings when the user changes his password. For that, we need to 
add a line

password        optional        pam_gnome_keyring.so

to the password block in /etc/pam.d/passwd.

This is optional, so it shouldn't break anything if gnome-keyring is not installed.

For more information, see http://live.gnome.org/GnomeKeyring/Pam
Comment 1 Tomas Mraz 2007-09-20 15:57:47 EDT
It should be added to the common system-auth config by authconfig.
Comment 2 Matthias Clasen 2007-10-03 10:20:58 EDT
So, we did a more thorough investigation of the issue today, and here is the
situation:

pam_gnome_keyring needs to be added to the auth and session stacks, in the auth
stack, it wants to be optional and remember the password for unlocking the
keyring later in the session stack, after starting the daemon.

The thing is: to get the password, it needs to sit after pam_unix (or
pam_ldap,...) in the stack. However, authconfig currently marks pam_unix as
sufficient, so pam_gnome_keyring never runs...

The plan we have come up with is to change authconfig to write out
[success=2 new_authtok_reqd=2 default=ignore] to skip the rest of system-auth
in the success case (of course, the number will have to be calculated based
on the number of modules in system-auth by authconfig). Then we can put
pam_gnome_keyring in the gdm stack after system-auth, and have it pick up the
password

in 
Comment 3 Matthias Clasen 2007-10-03 10:41:23 EDT
Ok, one more detail:

We've seen problems when just trying over the end of system-auth for
configuration where nothing comes after system-auth, like su. What works is to
jump to a 
pam_permit.so at the very end of system-auth
Comment 4 Alexander Larsson 2007-10-04 02:35:57 EDT
I was thinking, that extra pam_permit is a bit dangerous. In the case where
pam_unix actually failed we have to jump over that at the end
Comment 5 Matthias Clasen 2007-10-04 09:10:01 EDT
That is true; or make the deny before it sufficient
Comment 6 Alexander Larsson 2007-10-05 06:34:48 EDT
If the deny is made sufficient, will that not cause problems in a similar way
for required or optional things running afterwards? I guess that doesn't matter
much, because we've failed anyway?

I looked at the pam.d scripts btw, and it seems like atd has a similar problem:
/etc/pam.d/atd:
auth            sufficient      pam_rootok.so
auth            include         system-auth
auth            required        pam_env.so

pam_env won't run if system-auth succeeds.
Comment 7 Marcela Mašláňová 2007-10-05 07:53:16 EDT
The problem with _at_ has been fixed in version at-3.1.10-17.fc8
Comment 8 Alexander Larsson 2007-10-05 08:10:36 EDT
Created attachment 217271 [details]
authconfig patch for skipping to end on success

This patch implements the jump-to-end on login success by counting the lines
left in the stack.

I had to make the deny requsite to stop evaluation before the permit.
Comment 9 Jonathan Underwood 2008-04-02 10:24:15 EDT
Any progress on getting this fixed for F-8? Currently gnome-keyring-pam remains
non-functional because of this bug.
Comment 10 James G. Brown III 2008-04-06 22:48:43 EDT
Any update on this? If there is anything I can do to help please advise. 

- James
Comment 11 Tomas Mraz 2008-04-07 03:43:33 EDT
The substack support is in pam-0.99.8.1-17.1 which is in F-8 so what's missing
is just to change the pam configuration in gdm package to replace 'include
system-auth' with 'substack system-auth' and do the same for passwd + add
pam_gnome_keyring.so.
Comment 12 Tomas Mraz 2008-04-07 05:40:41 EDT
Actually the situation is not so good.
I've tried to add pam_gnome_keyring.so to passwd pam stack and:

1. I've got these AVCs from SElinux -
----
time->Mon Apr  7 09:51:30 2008
type=SYSCALL msg=audit(1207554690.613:26250): arch=c000003e syscall=6
success=yes exit=0 a0=614445 a1=7fff413def10 a2=7fff413def10 a3=2aaaaaee4820
items=0 ppid=8353 pid=8358 auid=501 uid=501 gid=501 euid=501 suid=501 fsuid=501
egid=501 sgid=501 fsgid=501 tty=pts4 comm="passwd" exe="/usr/bin/passwd"
subj=unconfined_u:system_r:passwd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1207554690.613:26250): avc:  denied  { getattr } for 
pid=8358 comm="passwd" path="/tmp/keyring-6O2TTA/socket" dev=dm-0 ino=4014744
scontext=unconfined_u:system_r:passwd_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:unconfined_tmp_t:s0 tclass=sock_file
----
time->Mon Apr  7 09:51:30 2008
type=SYSCALL msg=audit(1207554690.614:26251): arch=c000003e syscall=42
success=yes exit=0 a0=4 a1=7fff413defc0 a2=6e a3=2aaaaaee4820 items=0 ppid=8353
pid=8358 auid=501 uid=501 gid=501 euid=501 suid=501 fsuid=501 egid=501 sgid=501
fsgid=501 tty=pts4 comm="passwd" exe="/usr/bin/passwd"
subj=unconfined_u:system_r:passwd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1207554690.614:26251): avc:  denied  { connectto } for 
pid=8358 comm="passwd" path="/tmp/keyring-6O2TTA/socket"
scontext=unconfined_u:system_r:passwd_t:s0-s0:c0.c1023
tcontext=unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket
type=AVC msg=audit(1207554690.614:26251): avc:  denied  { write } for  pid=8358
comm="passwd" name="socket" dev=dm-0 ino=4014744
scontext=unconfined_u:system_r:passwd_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:unconfined_tmp_t:s0 tclass=sock_file

2. even with setenforce 0 the keyring password is not changed and this was
logged in /var/log/secure:

Apr  7 11:36:21 vespa passwd: gkr-pam: couldn't change password for 'login'
keyring: 1
Comment 13 Jonathan Underwood 2008-04-07 07:10:28 EDT
(In reply to comment #12)
> 2. even with setenforce 0 the keyring password is not changed and this was
> logged in /var/log/secure:
> 
> Apr  7 11:36:21 vespa passwd: gkr-pam: couldn't change password for 'login'
> keyring: 1
> 

Does deleting the login keyring fix this? Not that that is a great solution :)
Comment 14 Tomas Mraz 2008-04-07 07:17:22 EDT
> 
> Does deleting the login keyring fix this? Not that that is a great solution :)

How does one delete the login keyring preferably with previous backup?
Comment 15 Jonathan Underwood 2008-04-07 07:40:06 EDT
Well, the keyrings are in ~/.gnome2/keyrings, so if you (re)move the
login.keyring file from there, that should do it. 

Incidentally, I notice on my system, I only have default.keyring, and no
login.keyring.
Comment 16 Tomas Mraz 2008-04-07 07:56:18 EDT
Apparently pam_gnome_keyring unlocks / changes password on the login keyring. If
you already have default keyring its password will not be changed. At least this
is what I see on my F-8 machine.
Comment 17 Jonathan Underwood 2008-04-07 08:41:23 EDT
Gah. This confusion in gnome between the login and the default keyrings keeps
being a problem. I can't work out what is cocrect and what isn't correct with
this. Should we have both? If not, which should we have?
Comment 18 Daniel Walsh 2008-04-08 09:05:29 EDT
So the passwd utility needs to be able to comunicate with this user stream socket?
Comment 19 Daniel Walsh 2008-04-08 09:13:54 EDT
SELinux is Fixed in selinux-policy-3.3.1-30.fc9
Comment 20 Jonathan Underwood 2008-04-08 09:18:16 EDT
(In reply to comment #16)
> Apparently pam_gnome_keyring unlocks / changes password on the login keyring. If
> you already have default keyring its password will not be changed. At least this
> is what I see on my F-8 machine.
> 

According to http://live.gnome.org/GnomeKeyring/Pam

Upon authenticating the user, the PAM module tries to unlock the 'login' keyring
with the password entered by the user.

    * If the 'login' keyring does not exist it is created with the user's password.
    * If the 'login' is the first and only keyring it will become the default
keyring.

So the fact that login.keyring hasn't been created for me indicates some problem
too.
Comment 21 Tomas Mraz 2008-04-08 14:22:35 EDT
One of the reasons why you don't have the login keyring could be because
pam_gnome_keyring was never called for you. IMO in situation the user's home
directory (+ keyrings) exist from a Fedora where the pam_gnome_keyring was not
called on first keyring creation the pam_gnome_keyring is not too useful as the
user will have another default keyring which will already contain some passwords
etc.

So there should be probably a tool which would move/copy contents of some
keyring to another one.
Comment 22 Jonathan Underwood 2008-04-09 09:23:14 EDT
(In reply to comment #21)
> One of the reasons why you don't have the login keyring could be because
> pam_gnome_keyring was never called for you. IMO in situation the user's home
> directory (+ keyrings) exist from a Fedora where the pam_gnome_keyring was not
> called on first keyring creation the pam_gnome_keyring is not too useful as the
> user will have another default keyring which will already contain some passwords
> etc.
> 

Well, to test this, I just created a new user account with gnome-pam-keyring
already installed. When I add some authentication details to evolution, as
keyring is created - default.keyring. But logging in didn't create a login
keyring, and no login.keyring is ever created.

$ rpm -qa | grep keyring
gnome-keyring-pam-2.20.3-1.fc8
gnome-python2-gnomekeyring-2.20.0-1.fc8
gnome-keyring-2.20.3-1.fc8
gnome-keyring-2.20.3-1.fc8
gnome-keyring-manager-2.20.0-1.fc8



Comment 23 BoneKracker 2008-04-14 08:01:18 EDT
This seems to work (maybe I've broken something else I haven't discovered yet).
 Please point out my stupidity if so.

1) In /etc/pam.d/gdm, reverse the order of:
auth       optional    pam_gnome_keyring.so
auth       include     system-auth

2) Add the missing line to the end of /etc/pam.d/passwd:
password   optional     pam_gnome_keyring.so

3) Delete the contents of users' ~/.gnome2/keyring directories and reboot (or
log all off and back on).

Upon login, users get ~/.gnome2/keyring/login.keyring.
Evolution treats this as the "default" keyring.
I haven't tested vs. NetworkManager or other customers of Gnome Keyring.

I suppose it may be necessary/wise to 
  echo "login" > ~/.gnome2/keyring/default
but it's okay so far without.
Comment 24 Bug Zapper 2008-05-13 23:06:12 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 25 Matthias Clasen 2008-12-10 23:52:07 EST
*** Bug 472882 has been marked as a duplicate of this bug. ***
Comment 26 Bug Zapper 2009-06-09 18:43:54 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 27 Bug Zapper 2009-07-14 12:33:19 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.