Seahorse issues

[Coleman Kane]

On Sat, 2008-04-12 at 13:00 -0400, Joe Marcus Clarke wrote:
> On Sat, 2008-04-12 at 12:43 -0400, Coleman Kane wrote:
> > On Fri, 2008-04-11 at 11:54 -0400, Joe Marcus Clarke wrote:
> > > On Fri, 2008-04-11 at 10:14 -0400, Coleman Kane wrote:
> > > > I removed your earleir patch, which has the side effect of causing 
> > > > gnome_keyring_memory_try_alloc(size) to act in a manner that violates 
> > > > its documentation, as well as causing the above bug. I then added the 
> > > > three patches to security/seahorse which I posted into 
> > > > http://bugzilla.gnome.org/show_bug.cgi?id=527193 today:
> > > >   * http://bugzilla.gnome.org/attachment.cgi?id=109055
> > > >   * http://bugzilla.gnome.org/attachment.cgi?id=109056
> > > >   * http://bugzilla.gnome.org/attachment.cgi?id=109057
> > > > 
> > > > These three alter the behavior of Seahorse in the manner I described 
> > > > above, and don't touch gnome-keyring. For all purposes, I *think* 
> > > > gnome-keyring is acting properly here. The consumer of gnome-keyring 
> > > 
> > > You're right.  I was hoping to hack g-k in such a way to avoid having to
> > > fix other broken consumers in the future.  Of course, my approach was
> > > very wrong.
> > > 
> > > > (seahorse) should first be testing if the features that it wants to use 
> > > > are actually provided by the library before it blindingly attempts to 
> > > > use them. This is, IMHO, why gnome-keyring provides the *_try(...) 
> > > > versions of its securemem alloc functions.
> > > 
> > > Fixing seahorse is the right thing to do.  The bug has been moved into
> > > gnome-keyring's court, so you way want to get them to move it back.
> > > 
> > > > 
> > > > Additionally, you'll get a seahorse g_warning about unavailable secure 
> > > > memory now too.
> > > 
> > > Thanks for your work here.  Feel free to commit these patches to our
> > > seahorse port.
> > > 
> > > Joe
> > > 
> > 
> > Joe,
> > 
> > I've got a revised version of the patch that allows the seahorse panel
> > applet to work properly, as well as all of the other seahorse-based
> > gadgetry that is installed with the security/seahorse port. This
> > performs the conditional alloc remappings inside of
> > seahorse-secure-memory.c, and warns the user appropriately when they
> > don't have mlock() privileges.
> 
> I like this approach.  It's much more central.
> 
> > 
> > I'm attaching the full patch to security/seahorse here for you to look
> > over. I'll submit a forward of this email to ports@ as well (so that we
> > don't incur the wrath of cross-post-thulu).
> > 
> > If it doesn't break anything, and seems to make this thing work for
> > everyone, then I'll commit it later on (probably tomorrow or Monday).
> > I'd like to give it time to simmer, in case there are more things
> > touched by this problem that might come up.
> > 
> > As for the mlock() privilege issue, I am not sure what we'll do about
> > that. It would be nice, at some point, to support that feature for
> > normal users. As long as I'm diligent about my swap-space, etc... and
> > access to my workstation, I'm *pretty* secure. Things like common-use
> > lab computers, etc... are probably more appropriate for this feature.
> 
> Yes, Linux allows this, but Solaris does not (Solaris and FreeBSD share
> the same behavior).  Perhaps it's something FreeBSD could allow via a
> sysctl.  The default would be to restrict mlock(2) to processes with an
> effective UID of 0, but the sysctl could change that behavior to allow
> normal users to make use of the feature.
> 
> Joe
> 

My understanding of the Linux implementation is that there's an rlimit
for mlock that restricts the maximum usage for unprivileged, and allows
unlimited usage for privileged users. This behavior is new as of kernel
2.6.9, and kernels 2.6.8 and earlier use similar semantics to what
FreeBSD and Solaris do now.

--
Coleman Kane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-gnome/attachments/20080412/01454659/attachment.pgp