From owner-freebsd-gnome@FreeBSD.ORG Sat Apr 12 17:14:49 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 3870D1065677 for ; Sat, 12 Apr 2008 17:14:49 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by mx1.freebsd.org (Postfix) with ESMTP id 971308FC0C for ; Sat, 12 Apr 2008 17:14:48 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA04.westchester.pa.mail.comcast.net with comcast id CdKs1Z0040ldTLk540GF00; Sat, 12 Apr 2008 17:13:05 +0000 Received: from discordia ([24.60.135.75]) by OMTA04.westchester.pa.mail.comcast.net with comcast id ChEl1Z00C1dmTCQ3Q00000; Sat, 12 Apr 2008 17:14:46 +0000 X-Authority-Analysis: v=1.0 c=1 a=aiIX5UjjAAAA:8 a=TNP5buqIsVqL46uUeC8A:9 a=RhikV8h83sYjkMXWrtUA:7 a=zLWIzxNnD8JcHVbW-Wc7VRm-lygA:4 a=LY0hPdMaydYA:10 a=u1INLqbq3uj7pUBxr9MA:9 a=CtjwQpNYhY7NuhtvRfKO6aIkOWQA:4 a=rPt6xJ-oxjAA:10 Received: by discordia (Postfix, from userid 103) id D89B01636F9; Sat, 12 Apr 2008 13:14:45 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.1.8-gr1 (2007-02-13) on discordia X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8-gr1 Received: from [172.20.1.3] (erwin.int.cokane.org [172.20.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by discordia (Postfix) with ESMTP id 8E29B1636F8; Sat, 12 Apr 2008 13:14:29 -0400 (EDT) From: Coleman Kane To: Joe Marcus Clarke In-Reply-To: <1208019652.82222.13.camel@shumai.marcuscom.com> References: <47FD09AC.2020907@FreeBSD.org> <1207776230.61729.28.camel@shumai.marcuscom.com> <47FD34E8.2000005@FreeBSD.org> <1207872846.87478.38.camel@shumai.marcuscom.com> <47FF66E3.8000304@FreeBSD.org> <47FF722B.109@FreeBSD.org> <1207929297.55415.13.camel@shumai.marcuscom.com> <1208018626.10093.7.camel@localhost> <1208019652.82222.13.camel@shumai.marcuscom.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-m7LpKMPYbpZXnNenp5nE" Organization: FreeBSD Project Date: Sat, 12 Apr 2008 13:14:20 -0400 Message-Id: <1208020460.10093.20.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 FreeBSD GNOME Team Port Cc: gnome@freebsd.org, imp@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 17:14:49 -0000 --=-m7LpKMPYbpZXnNenp5nE Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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=20 > > > > gnome_keyring_memory_try_alloc(size) to act in a manner that violat= es=20 > > > > its documentation, as well as causing the above bug. I then added t= he=20 > > > > three patches to security/seahorse which I posted into=20 > > > > http://bugzilla.gnome.org/show_bug.cgi?id=3D527193 today: > > > > * http://bugzilla.gnome.org/attachment.cgi?id=3D109055 > > > > * http://bugzilla.gnome.org/attachment.cgi?id=3D109056 > > > > * http://bugzilla.gnome.org/attachment.cgi?id=3D109057 > > > >=20 > > > > These three alter the behavior of Seahorse in the manner I describe= d=20 > > > > above, and don't touch gnome-keyring. For all purposes, I *think*=20 > > > > gnome-keyring is acting properly here. The consumer of gnome-keyrin= g=20 > > >=20 > > > 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. > > >=20 > > > > (seahorse) should first be testing if the features that it wants to= use=20 > > > > are actually provided by the library before it blindingly attempts = to=20 > > > > use them. This is, IMHO, why gnome-keyring provides the *_try(...)=20 > > > > versions of its securemem alloc functions. > > >=20 > > > Fixing seahorse is the right thing to do. The bug has been moved int= o > > > gnome-keyring's court, so you way want to get them to move it back. > > >=20 > > > >=20 > > > > Additionally, you'll get a seahorse g_warning about unavailable sec= ure=20 > > > > memory now too. > > >=20 > > > Thanks for your work here. Feel free to commit these patches to our > > > seahorse port. > > >=20 > > > Joe > > >=20 > >=20 > > Joe, > >=20 > > 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. >=20 > I like this approach. It's much more central. >=20 > >=20 > > 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). > >=20 > > 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. > >=20 > > 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. >=20 > 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. >=20 > Joe >=20 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 --=-m7LpKMPYbpZXnNenp5nE Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEABECAAYFAkgA7ekACgkQcMSxQcXat5dlQACeIy9xowFcBm/MVwjVchTxdue1 caAAmwQqMtPW/Y0SRb8UjoLKL+jCLjTM =u9pH -----END PGP SIGNATURE----- --=-m7LpKMPYbpZXnNenp5nE--