Bug 250147

It should be added to the common system-auth config by authconfig.

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 

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

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

That is true; or make the deny before it sufficient

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.

The problem with _at_ has been fixed in version at-3.1.10-17.fc8

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.

Any progress on getting this fixed for F-8? Currently gnome-keyring-pam remains
non-functional because of this bug.

Any update on this? If there is anything I can do to help please advise. 

- James

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.

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

(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 :)

> 
> 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?

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.

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.

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?

So the passwd utility needs to be able to comunicate with this user stream socket?

SELinux is Fixed in selinux-policy-3.3.1-30.fc9

(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.

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.

(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

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.

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

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

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

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.