Re: gnome-keyring bug in snapshots

[Christopher Faylor <cgf-use-the-mailinglist-please@cygwin.com>]

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