Re: gnome-keyring Seahorse and clear text passwords: a proposal for a pragmatic solution

[Neil Broadley <scaine scaine net>]

> Well, I'm not even sure I'm suggesting that, although I can see the merit.
> No, really, I'm comparing Seahorse to the "change password" function in
> "about me".  In that app, you enter your current password to prove you are
> who you say you are (the logged in user), then you can change your
> password.  All I'm suggesting is a similar process in Seahorse when someone
> presses "reveal password".

Changing the password in the AboutMe controller mirrors the passwd
command.  The old password is needed to set the new one.

True, but I don't think it exactly mirrors "passwd".  I can enter my password correctly, it unlocks the "new password" entries, but without entering anything, I can just abandon the process and step away.  Can the "reveal password" box in Seahorse not re-use this behaviour, such that only after a successful authenticate, does it unhash the passwords into clear text?
 

> Basically, the "reveal password" tick would become a button triggering a
> password prompt.  If correct, password is revealed.  If not, it denies
> access, in the same way that policy kit does if you choose "deny".

The problem is that there's no where currently to check the entered
password.  The only solution currently to this is to lock and then
unlock the keyring as stated previously.

I'm not suggesting that the keyring is the issue here, only Seahorse's insistence on showing the passwords in clear text if I click on "reveal password".
 

 

> The problem at the moment is that policy kit prompts you "deny", "allow
> once" or "allow always", but since the default/login keyring is already
> unlocked, you don't get a password prompt.

This prompt comes from gnome-keyring and not from seahorse or
PolicyKit.  In fact, as has been discussed in this thread, the GNOME
bug report, or the one on seahorse-list, many distributions patch this
dialog out.

 

Are you sure?  The prompt that appears says "The application Seahorse /usr/bin/seahorse wishes to access the password caldav://blah/blah/blah in the default keyring".  I thought that if you're actively making that call to the keyring from Seahorse, it should be a relatively simple matter to prompt for authentication before making the call to the keyring?
 

>> At least the concept of having the keyrings live in another security
>> context is interesting. I haven't thought about this much, so I don't
>> know whether it would cause more problems than it would solve. But this
>> bears thinking about in the long term.
>
> I think something like this already happens at some level, because I noticed
> recently that in Network Manager (which uses gnome-keyring and whose
> passwords are therefore visible in Seahorse) if you tick "Available to all
> users" for a given WEP/WPA key, it vanishes from the login keyring in my
> user profile.  Perhaps it uses a root keyring?  Apologies, I'm not fully
> familiar with the underlying processes.  The last couple of weeks have been
> a steep learning curve.

It's probably editing a system configuration file.

Yeah, looks like it.  Certainly, if I run sudo -i, then run Seahorse, it complains that there's no keyring-daemon running, so that would appear to suggest that it's just using a system file somewhere.  However, as long as the rights on that file are owned by root and unreadable by group or other, I'm cool with that.

Thanks for responding to this.  There's been a lot of blogging on this and the Ubuntuforums thread is massive (only now, after nearly 400 posts, are things calming down).  People are passionate about this on both sides of the divide, so I appreciate the responses, wherever they might lead.