Bug 723339

It should be created. Are you using autologin?

No, I log in manually.

Hrm. Could it be that you created a keyring once, but not during login (maybe after an initial autologin)? Can you test with a brand new user?

Can you also grep your /var/log/messages for gkr-pam and keyring?

(I assume you're using GNOME, btw.)

I have not created a keyring, manually.

And I am using GNOME 3.2, of course ;)

I could also reproduce the problem on a fresh install. Maybe the difference is that I have not set up sudo (use this password for the administrator account) during installation.

Okay, we're back with an old issue: gnome-keyring-pam is misconfigured after installation: /etc/pam.d/ has only a partial gnome-keyring configuration as /etc/pam.d/common-auth doesn't contain the pam_gnome_keyring bits.

It's worth mentioning that /etc/pam.d/common-session and /etc/pam.d/common-password both contain the pam_gnome_keyring bits, so there is something tweaking the pam configuration without pam-config, and it breaks gnome-keyring.

I'm afraid it might be some hack we run on the live images. At least when looking at the pam configuration on a live image, I see the pam_gnome_keyring bits are commented in common-auth, so maybe the installed system inherits that.

Coolo, do you know where the pam configuration is tweaked for live systems?

09:21 < coolo> vuntz: user setup is /usr/share/opensuse-kiwi/live_user_scripts/*.sh
09:21 < coolo> and then there is correct_live_for_reboot and correct_live_install used by live installed

Looking at those scripts, they do the right thing. So things get broken by something else.

I did several test installs to identify when common-auth is changed. Apparently, this is during the "Save installation settings" step in yast.

Lukas: do you know who in the yast team could help me debug this? There's something changing /etc/pam.d/ files during the installation (could be with a call to pam-config, but I doubt so), and I'm unsure how to identify the relevant code.

Vincent: If there was any change in pam config settings, Jiri
should know that as he maintains auth code in YaST.

(In reply to comment #8)
> Vincent: If there was any change in pam config settings, Jiri
> should know that as he maintains auth code in YaST.

FWIW, I'm not sure if it's a recent change or not: I've heard people having similar issues in 11.3 or 11.4, so it might well be an old issue.

I guess this is bug 697670.

The question remains same as there: can you check the modification time of those pam files and attach y2log so we can compare and possible find what has changed them?

Created attachment 457876 [details]
y2log from first stage installer

All the /etc/pam.d/common-*-pc have this modification time: 15:58:16.748010056

So this is the issue:

2011-10-20 15:58:16 <1> linux.site(2481) [YCP] Bootloader.ycp:1535 handleSELinuxPAM called
2011-10-20 15:58:16 <1> linux.site(2481) [YCP] Bootloader.ycp:1543 call disableSELinuxPAM

It turns out that this calls pam-config:

void disableSELinuxPAM ()
{
    string cmd_disable_se = "pam-config -d --selinux  2>/dev/null";
    string cmd_enable_aa  = "pam-config -a --apparmor 2>/dev/null";

    map out = (map) SCR::Execute (.target.bash, cmd_disable_se);
    y2debug("result of disabling the SELinux PAM module is %1", out);

    out = (map) SCR::Execute (.target.bash, cmd_enable_aa);
    y2debug("result of enabling the AppArmor PAM module is %1", out);
}

And this apparently breaks the hack we have in kiwi-config-openSUSE where we temporarily comment out the pam_gnome_keyring bit in /etc/pam.d/common-auth-pc.

Not sure how we should handle that :/

Wow. I had no idea bootloader code calls pam-config.

How can know if the code is wrong or kiwi-config-openSUSE? Coolo?

That was fate #309275 apparently.

Anyway, calling pam-config looks not so forbidden to me.

I'd say the hack in kiwi-config-openSUSE is not solid enough, so not an issue on yast's side there. I'm trying to figure out how to make the kiwi-config-openSUSE hack more solid, without changing everything.

thanks

Fix submitted: sr#88934.

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