gnome-keyring bug in snapshots

gnome-keyring bug in snapshots

[Yaakov (Cygwin/X)]

For some time now, snapshots have displayed a bug wrt gnome-keyring,
namely that passwords don't "register" when entered.  This wreaks
havoc on the GNOME desktop where so many programs rely on
gnome-keyring.

This is easy to reproduce, but requires xorg-server, dbus,
gnome-keyring, and openssh.  At a new terminal:

$ XWin -multiwindow &>/dev/null &
$ export DISPLAY=:0
$ eval `dbus-launch --sh-syntax`
$ export `gnome-keyring-daemon --start --components=ssh`
$ ssh USER@HOSTNAME
(Enter password for ssh key in GUI prompt)

What should happen (and does with 1.7.9) is a successful login.  WIth
the 20111129 snapshot, the following message is displayed on the
terminal:

Agent admitted failure to sign using the key.

(which AFAIK comes from ssh) and the gnome-keyring prompt asks for the
password to the next private key listed in ~/.ssh/config (even if its
the wrong key for HOSTNAME).  Subsequent logins do succeed, however.
This does not occur with ssh-agent(1).

Frankly, I'm a little baffled by this one, but a non-working GNOME
desktop is really keeping me from testing the snapshots for any length
of time.


Yaakov
Cygwin/X

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: gnome-keyring bug in snapshots

[Christopher Faylor]

On Tue, Nov 29, 2011 at 09:19:10PM -0600, Yaakov (Cygwin/X) wrote:
>For some time now, snapshots have displayed a bug wrt gnome-keyring,
>namely that passwords don't "register" when entered.  This wreaks
>havoc on the GNOME desktop where so many programs rely on
>gnome-keyring.
>
>This is easy to reproduce, but requires xorg-server, dbus,
>gnome-keyring, and openssh.  At a new terminal:
>
>$ XWin -multiwindow &>/dev/null &
>$ export DISPLAY=:0
>$ eval `dbus-launch --sh-syntax`
>$ export `gnome-keyring-daemon --start --components=ssh`
>$ ssh USER@HOSTNAME
>(Enter password for ssh key in GUI prompt)
>
>What should happen (and does with 1.7.9) is a successful login.  WIth
>the 20111129 snapshot, the following message is displayed on the
>terminal:
>
>Agent admitted failure to sign using the key.
>
>(which AFAIK comes from ssh) and the gnome-keyring prompt asks for the
>password to the next private key listed in ~/.ssh/config (even if its
>the wrong key for HOSTNAME).  Subsequent logins do succeed, however.
>This does not occur with ssh-agent(1).
>
>Frankly, I'm a little baffled by this one, but a non-working GNOME
>desktop is really keeping me from testing the snapshots for any length
>of time.

I'm looking at this now.

FYI.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: gnome-keyring bug in snapshots

[Christopher Faylor]

On Sat, Dec 03, 2011 at 01:44:59PM -0500, Christopher Faylor wrote:
>On Tue, Nov 29, 2011 at 09:19:10PM -0600, Yaakov (Cygwin/X) wrote:
>>For some time now, snapshots have displayed a bug wrt gnome-keyring,
>>namely that passwords don't "register" when entered.  This wreaks
>>havoc on the GNOME desktop where so many programs rely on
>>gnome-keyring.
>>
>>This is easy to reproduce, but requires xorg-server, dbus,
>>gnome-keyring, and openssh.  At a new terminal:
>>
>>$ XWin -multiwindow &>/dev/null &
>>$ export DISPLAY=:0
>>$ eval `dbus-launch --sh-syntax`
>>$ export `gnome-keyring-daemon --start --components=ssh`
>>$ ssh USER@HOSTNAME
>>(Enter password for ssh key in GUI prompt)
>>
>>What should happen (and does with 1.7.9) is a successful login.  WIth
>>the 20111129 snapshot, the following message is displayed on the
>>terminal:
>>
>>Agent admitted failure to sign using the key.
>>
>>(which AFAIK comes from ssh) and the gnome-keyring prompt asks for the
>>password to the next private key listed in ~/.ssh/config (even if its
>>the wrong key for HOSTNAME).  Subsequent logins do succeed, however.
>>This does not occur with ssh-agent(1).
>>
>>Frankly, I'm a little baffled by this one, but a non-working GNOME
>>desktop is really keeping me from testing the snapshots for any length
>>of time.
>
>I'm looking at this now.

strace output led me to starting syslog to see what gnome-keyring-daemon
was complaining about.  I'm seeing this:

Dec  3 16:22:55 norton gnome-keyring-daemon: PID 1136: couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files
Dec  3 16:22:55 norton gnome-keyring-daemon: PID 1136: couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files
Dec  3 16:22:56 norton gnome-keyring-daemon: PID 1136: couldn't allocate secure memory to keep passwords and or keys from being written to the disk
Dec  3 16:22:56 norton gnome-keyring-daemon: PID 1136: unsupported key algorithm in certificate: 1.2.840.10045.2.1
Dec  3 16:22:56 norton last message repeated 4 times
Dec  3 16:22:56 norton gnome-keyring-daemon: PID 1136: couldn't parse certificate data
Dec  3 16:22:56 norton gnome-keyring-daemon: PID 1136: couldn't parse certificate(s): /usr/ssl/certs/ca-bundle.trust.crt
Dec  3 16:22:56 norton gnome-keyring-daemon: PID 1136: couldn't parse certificate data
Dec  3 16:22:56 norton gnome-keyring-daemon: PID 1136: couldn't parse certificate(s): /usr/ssl/certs/README.RootCerts
Dec  3 16:22:56 norton sshd: PID 724: Address ::1 maps to norton, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Dec  3 16:22:56 norton gnome-keyring-prompt: Pango: No such file or directory
Dec  3 16:22:57 norton gnome-keyring-prompt: couldn't allocate secure memory to keep passwords and or keys from being written to the disk
Dec  3 16:22:59 norton gnome-keyring-daemon: PID 1136: GLib: Failed to read from child watch wake up pipe: Interrupted system call
Dec  3 16:22:59 norton gnome-keyring-daemon: PID 1136: gku_prompt_get_response: assertion `self->pv->output' failed

According to strace, the "couldn't allocate secure memory..." messages
seems to be caused by this:

gnome-keyring-daemon 3820 seterrno_from_nt_status: /cygnus/src/uberbaum/winsup/cygwin/mmap.cc:1399 status 0xC0000061

That is coming from mlock() which hasn't changed in months.

The status above translates to: STATUS_PRIVILEGE_NOT_HELD and that is
coming from NtLockVirtualMemory() .

Yaakov or Corinna does any of the above mean anything to you?

cgf


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: gnome-keyring bug in snapshots

[Corinna Vinschen]

On Dec  3 16:30, Christopher Faylor wrote:
> On Sat, Dec 03, 2011 at 01:44:59PM -0500, Christopher Faylor wrote:
> >On Tue, Nov 29, 2011 at 09:19:10PM -0600, Yaakov (Cygwin/X) wrote:
> >>For some time now, snapshots have displayed a bug wrt gnome-keyring,
> >>namely that passwords don't "register" when entered.  This wreaks
> >>havoc on the GNOME desktop where so many programs rely on
> >>gnome-keyring.
> >>[...]
> According to strace, the "couldn't allocate secure memory..." messages
> seems to be caused by this:
> 
> gnome-keyring-daemon 3820 seterrno_from_nt_status: /cygnus/src/uberbaum/winsup/cygwin/mmap.cc:1399 status 0xC0000061
> 
> That is coming from mlock() which hasn't changed in months.
> 
> The status above translates to: STATUS_PRIVILEGE_NOT_HELD and that is
> coming from NtLockVirtualMemory() .
> 
> Yaakov or Corinna does any of the above mean anything to you?

As documented in mmap.cc, mlock functionality requires the SE_LOCK_MEMORY
privilege which only the SYSTEM account holds by default.  Mlock is
unchanged since it has been introduced in 2005.

Having said that, after searching the net for a while I found out that
the privilege requirement is excessive.  In 2005 I stumbled over the
wrong interpretation of what the VirtualLock function is doing.  Not
even Microsoft guys are immune to that(*), apparently.

I dropped the requirement for the SE_LOCK_MEMORY privilege in CVS so
every process should be able to call mlock successfully now.


Corinna

(*) http://blogs.msdn.com/b/oldnewthing/archive/2007/11/06/5924058.aspx
    See the last paragraph.


-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: gnome-keyring bug in snapshots

[Christopher Faylor]

On Sun, Dec 04, 2011 at 12:04:08AM +0100, Corinna Vinschen wrote:
>On Dec  3 16:30, Christopher Faylor wrote:
>> On Sat, Dec 03, 2011 at 01:44:59PM -0500, Christopher Faylor wrote:
>> >On Tue, Nov 29, 2011 at 09:19:10PM -0600, Yaakov (Cygwin/X) wrote:
>> >>For some time now, snapshots have displayed a bug wrt gnome-keyring,
>> >>namely that passwords don't "register" when entered.  This wreaks
>> >>havoc on the GNOME desktop where so many programs rely on
>> >>gnome-keyring.
>> >>[...]
>> According to strace, the "couldn't allocate secure memory..." messages
>> seems to be caused by this:
>> 
>> gnome-keyring-daemon 3820 seterrno_from_nt_status: /cygnus/src/uberbaum/winsup/cygwin/mmap.cc:1399 status 0xC0000061
>> 
>> That is coming from mlock() which hasn't changed in months.
>> 
>> The status above translates to: STATUS_PRIVILEGE_NOT_HELD and that is
>> coming from NtLockVirtualMemory() .
>> 
>> Yaakov or Corinna does any of the above mean anything to you?
>
>As documented in mmap.cc, mlock functionality requires the SE_LOCK_MEMORY
>privilege which only the SYSTEM account holds by default.  Mlock is
>unchanged since it has been introduced in 2005.
>
>Having said that, after searching the net for a while I found out that
>the privilege requirement is excessive.  In 2005 I stumbled over the
>wrong interpretation of what the VirtualLock function is doing.  Not
>even Microsoft guys are immune to that(*), apparently.
>
>I dropped the requirement for the SE_LOCK_MEMORY privilege in CVS so
>every process should be able to call mlock successfully now.

Thanks.  As you surmised this had nothing to do with the problem.  It
apparently just a random error in a log file from gnome-keyring-daemon.

The real problem seemed to be a change introduced after 1.7.9 which
subtly broke the handling of signals during I/O.  That should be fixed
in the latest snapshot but, like so much of what I've worked on in Cygwin
lately, it touched a fundamental part of the code.  I wish I hadn't had
to make this change just before 1.7.10 but, in theory, it should make
it possible for a signal handler to be caught in a thread - that's a first
for Cygwin and it's something I've been meaning to get to for a while.

This isn't perfect though and I hope that doesn't mean that I've
introduced other corner case problems.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: gnome-keyring bug in snapshots

[Yaakov (Cygwin/X)]

On Sun, 2011-12-04 at 14:27 -0500, Christopher Faylor wrote:
> The real problem seemed to be a change introduced after 1.7.9 which
> subtly broke the handling of signals during I/O.  That should be fixed
> in the latest snapshot but, like so much of what I've worked on in Cygwin
> lately, it touched a fundamental part of the code.  I wish I hadn't had
> to make this change just before 1.7.10 but, in theory, it should make
> it possible for a signal handler to be caught in a thread - that's a first
> for Cygwin and it's something I've been meaning to get to for a while.

The 20111204 snapshot fixes gnome-keyring.  Thanks!

> This isn't perfect though and I hope that doesn't mean that I've
> introduced other corner case problems.

I'll continue testing CVS HEAD and see what happens.  How much more
churn are you planning before 1.7.10?


Yaakov



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: gnome-keyring bug in snapshots

[Christopher Faylor]

On Sun, Dec 04, 2011 at 08:03:18PM -0600, Yaakov (Cygwin/X) wrote:
>On Sun, 2011-12-04 at 14:27 -0500, Christopher Faylor wrote:
>> The real problem seemed to be a change introduced after 1.7.9 which
>> subtly broke the handling of signals during I/O.  That should be fixed
>> in the latest snapshot but, like so much of what I've worked on in Cygwin
>> lately, it touched a fundamental part of the code.  I wish I hadn't had
>> to make this change just before 1.7.10 but, in theory, it should make
>> it possible for a signal handler to be caught in a thread - that's a first
>> for Cygwin and it's something I've been meaning to get to for a while.
>
>The 20111204 snapshot fixes gnome-keyring.  Thanks!

That's a relief.  I have to admit that this is one of the few times that
I fixed a problem without first understanding the root cause.  I saw
that there was something fishy going on but it didn't seem to relate to
the gnome-keyring problem.  But after several stabs at fixing the fishy
problem, the gnome-keyring problem vanished.

>> This isn't perfect though and I hope that doesn't mean that I've
>> introduced other corner case problems.
>
>I'll continue testing CVS HEAD and see what happens.  How much more
>churn are you planning before 1.7.10?

I think (unless Corinna disagrees) that the current snapshot should be
considered 1.7.10rc1.  I really don't want to perturb the source code
any more now unless it's absolutely necessary.  Even this current fix is
basically just a band-aid.  I hope to rework some of the signal handling
for 1.7.11 to make things a little less ugly.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple