From owner-freebsd-gnome@FreeBSD.ORG Sat Apr 12 18:38:08 2008 Return-Path: Delivered-To: gnome@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4851D106564A; Sat, 12 Apr 2008 18:38:08 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id D46A28FC0C; Sat, 12 Apr 2008 18:38:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m3CIbiYU045174; Sat, 12 Apr 2008 12:37:44 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 12 Apr 2008 12:38:45 -0600 (MDT) Message-Id: <20080412.123845.-216597985.imp@bsdimp.com> To: cokane@freebsd.org From: "M. Warner Losh" In-Reply-To: <1208020460.10093.20.camel@localhost> References: <1208018626.10093.7.camel@localhost> <1208019652.82222.13.camel@shumai.marcuscom.com> <1208020460.10093.20.camel@localhost> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: gnome@freebsd.org Subject: Re: Seahorse issues X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2008 18:38:08 -0000 In message: <1208020460.10093.20.camel@localhost> Coleman Kane writes: : 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. That's actually not a bad idea... But we need to be careful to make sure that fork can't be used to multiply the rlimit and make a DoS possible. Warner