Re: gnome-keyring Seahorse and clear text passwords: a proposal for a pragmatic solution
- From: Adam Schreiber <adam schreiber gmail com>
- To: Neil Broadley <scaine scaine net>
- Cc: seahorse-list gnome org, Vertigo <duvel123 gmail com>, stef memberwebs com, gnome-keyring-list gnome org
- Subject: Re: gnome-keyring Seahorse and clear text passwords: a proposal for a pragmatic solution
- Date: Wed, 4 Nov 2009 19:38:47 -0500
2009/11/4 Neil Broadley <scaine scaine net>:
>
>
> 2009/11/3 Stef Walter <stef-list memberwebs com>
>>
>> Neil Broadley wrote:
>> > Can I add that I don't think the solution needs to be "lock seahorse and
>> > require a password to use it". I just think that when Seahorse is
>> > accessed, passwords are by default not shown in clear text. Since this
>> > is possibly not fully useful, a button to "Reveal passwords" would then
>> > prompt via gksudo/policykit/whatever.
>>
>> So what you're suggesting is to have the keyrings live in a daemon
>> running as root, essentially another security context, which then uses
>> policykit or gksudo for permisions? An interesting idea. Certainly
>> non-trivial, and needs a lot more thought, but interesting
>
> 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.
> 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.
> 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.
>> 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.
> (p.s. I'm replying to all to post this message from gmail - is that the
> correct procedure here?)
Yes, reply-all is the correct thing to do when replying to a list that
keeps the last sender in the reply-to field of the headers. There are
some lists that all you have to do is hit reply. Most GNOME lists are
not among them.
Cheers,
Adam
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]