Date: Sat, 12 Apr 2008 13:00:52 -0400 From: Joe Marcus Clarke <marcus@marcuscom.com> To: Coleman Kane <cokane@freebsd.org> Cc: gnome@freebsd.org, imp@freebsd.org Subject: Re: Seahorse issues Message-ID: <1208019652.82222.13.camel@shumai.marcuscom.com> In-Reply-To: <1208018626.10093.7.camel@localhost> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-RdS8JqFN5ofGP+1Srjvu Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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 violates= =20 > > > its documentation, as well as causing the above bug. I then added the= =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 described=20 > > > above, and don't touch gnome-keyring. For all purposes, I *think*=20 > > > gnome-keyring is acting properly here. The consumer of gnome-keyring=20 > >=20 > > You're right. I was hoping to hack g-k in such a way to avoid having t= o > > 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 u= se=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 into > > 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 secur= e=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. I like this approach. It's much more central. >=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. 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 --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-RdS8JqFN5ofGP+1Srjvu 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) iEYEABECAAYFAkgA6sQACgkQb2iPiv4Uz4c+xwCeJHLkc3Tjaeh8mNO4Kkh9baNM r4wAn3Y94JJA8FQM/QW96A1Oes18gLN0 =ePx0 -----END PGP SIGNATURE----- --=-RdS8JqFN5ofGP+1Srjvu--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1208019652.82222.13.camel>