Hide Forgot
Description of problem: When trying to change the user password using the gnome panel --> "Account Information" --> "change password..." button, the password change dialogue hangs, although can be ended using the cancel button. The user password is changed nevertheless, but the password of the gnome-keyring is not changed. The SElinux Alerts are quoted in the attached file Version-Release number of selected component (if applicable): Source RPM Packages gnome-keyring-2.32.1-1.fc14 Target RPM Packages filesystem-2.4.35-1.fc14 Policy RPM selinux-policy-3.9.7-25.fc14 How reproducible: everytime Steps to Reproduce: 1. Log in 2. Open gnome panel's "Account Information" 3. Click button "Change password..." 4. Enter old and enter/confirm new passwords 5. Click "Change password..." button Actual results: The dialogue does not complete but can be finished via the cancel button. The user account's password is changed. The gnome-keyring password remains unchanged. Expected results: Both the user account's password and the gnome-keyring password should be changed in one go without SElinux to interfere. Additional info:
Created attachment 476283 [details] SETroubleshooting Details (initial attaching of the file failed)
passwd (passwd_t) wants to run (restart) gnome-keyring-daemon: $ less /etc/pam.d/passwd #%PAM-1.0 auth include system-auth account include system-auth password substack system-auth -password optional pam_gnome_keyring.so use_authtok Since passwd_t is allowed corecmd_exec_bin(), gnome-keyring-daemon runs in passwd_t domain when it tries to create a directory (and socket) in /tmp, which is denied. A solution would be to somehow allow passwd_t to run bin_t files in the calling user domain (corecmd_bin_domtrans) however the passwd domain is not "role prefixed" and so allowing passwd_t to run bin_t files in the calling user domain is not a good idea unless we prefix passwd_t ($1_passwd_t) i guess.
Yes, there is no way we can get this transition correct. The problem is the gnome-keyring-daemon was not running and should not be started by pam module if it is not running. Try to start gnome-keyring then should work fine.
As far as i know gnome-keyring-daemon is already running. Can you confirm this Ralf? Should be easy to reproduce by just choosing "Account information" then "change password". Why is passwd_t allowed to run bin_t files? In upstream refpolicy this is not allowed, and in my personal policy (for Fedora 14) passwd_t is also not allowed to corecmd_exec_bin(passwd_t) and i do not notice any loss in functionality.
(In reply to comment #4) > As far as i know gnome-keyring-daemon is already running. Can you confirm this > Ralf? > > Should be easy to reproduce by just choosing "Account information" then "change > password". # ps -eZ | grep gnome-key unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 3117 ? 00:00:00 gnome-keyring-d and I am not able to reproduce it. > > Why is passwd_t allowed to run bin_t files? In upstream refpolicy this is not > allowed, and in my personal policy (for Fedora 14) passwd_t is also not allowed > to corecmd_exec_bin(passwd_t) and i do not notice any loss in functionality. Yes, it looks like a bug in our policy which should be fixed.
Just to make sure, did you enter a different new password? I was not able to reproduce it at first either, turned out that this may have been due to me trying to reset the old password to the same new password. Unfortunately i cannot fully reproduce this issue because i use custom policy, which breaks some gnome-keyring-daemon functionality in the first place. However, i was able to reproduce the issue where passwd_t tried to run gnome-keyring-daemon when gnome-keyring-daemon was already running.
https://bugzilla.redhat.com/show_bug.cgi?id=540367 Looks like it was added by me. I wonder if passwd_t is executing gnome-keyring-daemon in a special way to talk to the running gome-keyring-daemon. grep keyring /etc/pam.d/passwd -password optional pam_gnome_keyring.so use_authtok
Moving to gnome-keyring (was 0xFFFF) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This behaviour is still visible in Fedora 15.
*** Bug 707803 has been marked as a duplicate of this bug. ***
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached 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, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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