Date: Sat, 12 Apr 2008 12:43:46 -0400 From: Coleman Kane <cokane@FreeBSD.org> To: Joe Marcus Clarke <marcus@marcuscom.com> Cc: gnome@freebsd.org, imp@freebsd.org Subject: Re: Seahorse issues Message-ID: <1208018626.10093.7.camel@localhost> In-Reply-To: <1207929297.55415.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>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-QU9gGQmVx5cG5PtPBIoB Content-Type: multipart/mixed; boundary="=-4lgvQw6sVZ+aCW4h2MeR" --=-4lgvQw6sVZ+aCW4h2MeR Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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 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 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 secure=20 > > memory now too. >=20 > Thanks for your work here. Feel free to commit these patches to our > seahorse port. >=20 > Joe >=20 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'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. -- Coleman Kane --=-4lgvQw6sVZ+aCW4h2MeR Content-Description: security_seahorse-no-mlock.patch Content-Disposition: inline; filename=security_seahorse-no-mlock.patch Content-Transfer-Encoding: base64 Content-Type: text/x-patch; charset=UTF-8 ZGlmZiAtLWdpdCBhL3NlY3VyaXR5L3NlYWhvcnNlL01ha2VmaWxlIGIvc2VjdXJpdHkvc2VhaG9y c2UvTWFrZWZpbGUNCmluZGV4IGEwNjVhMDkuLmQ1ZDQxN2YgMTAwNjQ0DQotLS0gYS9zZWN1cml0 eS9zZWFob3JzZS9NYWtlZmlsZQ0KKysrIGIvc2VjdXJpdHkvc2VhaG9yc2UvTWFrZWZpbGUNCkBA IC04LDYgKzgsNyBAQA0KIA0KIFBPUlROQU1FPQlzZWFob3JzZQ0KIFBPUlRWRVJTSU9OPQkyLjIy LjENCitQT1JUUkVWSVNJT049CTENCiBDQVRFR09SSUVTPQlzZWN1cml0eSBnbm9tZQ0KIE1BU1RF Ul9TSVRFUz0JR05PTUUNCiBESVNUX1NVQkRJUj0JZ25vbWUyDQpkaWZmIC0tZ2l0IGEvc2VjdXJp dHkvc2VhaG9yc2UvZmlsZXMvcGF0Y2gtbGlic2VhaG9yc2Vfc2VhaG9yc2Utc2VjdXJlLW1lbW9y eS5jIGIvc2VjdXJpdHkvc2VhaG9yc2UvZmlsZXMvcGF0Y2gtbGlic2VhaG9yc2Vfc2VhaG9yc2Ut c2VjdXJlLW1lbW9yeS5jDQpuZXcgZmlsZSBtb2RlIDEwMDY0NA0KaW5kZXggMDAwMDAwMC4uNGE2 MzAwYg0KLS0tIC9kZXYvbnVsbA0KKysrIGIvc2VjdXJpdHkvc2VhaG9yc2UvZmlsZXMvcGF0Y2gt bGlic2VhaG9yc2Vfc2VhaG9yc2Utc2VjdXJlLW1lbW9yeS5jDQpAQCAtMCwwICsxLDQyIEBADQor LS0tIGxpYnNlYWhvcnNlL3NlYWhvcnNlLXNlY3VyZS1tZW1vcnkuYy5vcmlnCTIwMDgtMDQtMTIg MTI6MDk6NTguMDAwMDAwMDAwIC0wNDAwDQorKysrIGxpYnNlYWhvcnNlL3NlYWhvcnNlLXNlY3Vy ZS1tZW1vcnkuYwkyMDA4LTA0LTEyIDEyOjEwOjA1LjAwMDAwMDAwMCAtMDQwMA0KK0BAIC05Nywx MyArOTcsMzEgQEANCisgdm9pZA0KKyBzZWFob3JzZV9zZWN1cmVfbWVtb3J5X2luaXQgKCkNCisg ew0KKy0gICAgR01lbVZUYWJsZSB2dGFibGU7DQorLSAgICANCistICAgIG1lbXNldCAoJnZ0YWJs ZSwgMCwgc2l6ZW9mICh2dGFibGUpKTsNCistICAgIHZ0YWJsZS5tYWxsb2MgPSBzd2l0Y2hfbWFs bG9jOw0KKy0gICAgdnRhYmxlLnJlYWxsb2MgPSBzd2l0Y2hfcmVhbGxvYzsNCistICAgIHZ0YWJs ZS5mcmVlID0gc3dpdGNoX2ZyZWU7DQorLSAgICB2dGFibGUuY2FsbG9jID0gc3dpdGNoX2NhbGxv YzsNCistICAgIGdfbWVtX3NldF92dGFibGUgKCZ2dGFibGUpOw0KKysgICAgaWYgKHNlYWhvcnNl X3RyeV9na19zZWN1cmVfbWVtb3J5KCkgPT0gVFJVRSkgew0KKysgICAgICAgIEdNZW1WVGFibGUg dnRhYmxlOw0KKysNCisrICAgICAgICBtZW1zZXQgKCZ2dGFibGUsIDAsIHNpemVvZiAodnRhYmxl KSk7DQorKyAgICAgICAgdnRhYmxlLm1hbGxvYyA9IHN3aXRjaF9tYWxsb2M7DQorKyAgICAgICAg dnRhYmxlLnJlYWxsb2MgPSBzd2l0Y2hfcmVhbGxvYzsNCisrICAgICAgICB2dGFibGUuZnJlZSA9 IHN3aXRjaF9mcmVlOw0KKysgICAgICAgIHZ0YWJsZS5jYWxsb2MgPSBzd2l0Y2hfY2FsbG9jOw0K KysgICAgICAgIGdfbWVtX3NldF92dGFibGUgKCZ2dGFibGUpOw0KKysgICAgfSBlbHNlIHsNCisr ICAgICAgICBnX3dhcm5pbmcgKCJVbmFibGUgdG8gYWxsb2NhdGUgc2VjdXJlIG1lbW9yeSBmcm9t IGdub21lLWtleXJpbmcuXG4iKTsNCisrICAgICAgICBnX3dhcm5pbmcgKCJQcm9jZWVkaW5nIHdp dGggaW5zZWN1cmUgcGFzc3dvcmQgbWVtb3J5IGluc3RlYWQuXG4iKTsNCisrICAgIH0NCisgfQ0K KyANCisrZ2Jvb2xlYW4NCisrc2VhaG9yc2VfdHJ5X2drX3NlY3VyZV9tZW1vcnkgKCkNCisrew0K KysgICAgZ3BvaW50ZXIgcDsNCisrDQorKyAgICBwID0gZ25vbWVfa2V5cmluZ19tZW1vcnlfdHJ5 X2FsbG9jICgxMCk7DQorKyAgICBpZiAocCAhPSBOVUxMKSB7DQorKyAgICAgICAgZ25vbWVfa2V5 cmluZ19tZW1vcnlfZnJlZSAocCk7DQorKyAgICAgICAgcmV0dXJuIFRSVUU7DQorKyAgICB9DQor Kw0KKysgICAgcmV0dXJuIEZBTFNFOw0KKyt9DQpkaWZmIC0tZ2l0IGEvc2VjdXJpdHkvc2VhaG9y c2UvZmlsZXMvcGF0Y2gtbGlic2VhaG9yc2Vfc2VhaG9yc2Utc2VjdXJlLW1lbW9yeS5oIGIvc2Vj dXJpdHkvc2VhaG9yc2UvZmlsZXMvcGF0Y2gtbGlic2VhaG9yc2Vfc2VhaG9yc2Utc2VjdXJlLW1l bW9yeS5oDQpuZXcgZmlsZSBtb2RlIDEwMDY0NA0KaW5kZXggMDAwMDAwMC4uMzU0YjU2Mw0KLS0t IC9kZXYvbnVsbA0KKysrIGIvc2VjdXJpdHkvc2VhaG9yc2UvZmlsZXMvcGF0Y2gtbGlic2VhaG9y c2Vfc2VhaG9yc2Utc2VjdXJlLW1lbW9yeS5oDQpAQCAtMCwwICsxLDExIEBADQorLS0tIGxpYnNl YWhvcnNlL3NlYWhvcnNlLXNlY3VyZS1tZW1vcnkuaC5vcmlnCTIwMDgtMDQtMTEgMDk6MzM6MzQu MDAwMDAwMDAwIC0wNDAwDQorKysrIGxpYnNlYWhvcnNlL3NlYWhvcnNlLXNlY3VyZS1tZW1vcnku aAkyMDA4LTA0LTExIDA5OjM0OjEyLjAwMDAwMDAwMCAtMDQwMA0KK0BAIC0zNCw2ICszNCw3IEBA DQorICAgICB9IHdoaWxlICgwKQ0KKyANCisgLyogVGhpcyBtdXN0IGJlIGNhbGxlZCBiZWZvcmUg YW55IGdsaWIvZ3RrL2dub21lIGZ1bmN0aW9ucyAqLw0KKy12b2lkICAgIHNlYWhvcnNlX3NlY3Vy ZV9tZW1vcnlfaW5pdCAgICAgICAgICh2b2lkKTsNCisrdm9pZCAgICAgc2VhaG9yc2Vfc2VjdXJl X21lbW9yeV9pbml0ICAgICAgICAgKHZvaWQpOw0KKytnYm9vbGVhbiBzZWFob3JzZV90cnlfZ2tf c2VjdXJlX21lbW9yeSAgICAgICh2b2lkKTsNCisgDQorICNlbmRpZiAvKiBfU0VBSE9SU0VfU0VD VVJFX01FTU9SWV9IXyAqLw0K --=-4lgvQw6sVZ+aCW4h2MeR-- --=-QU9gGQmVx5cG5PtPBIoB 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) iEYEABECAAYFAkgA5r8ACgkQcMSxQcXat5cgxgCbBxkjBKM7SIvvU1qbjc5ddF80 ydQAnjVUE4pT+Wg/3m0we0JcrvnHqIv3 =7Pa9 -----END PGP SIGNATURE----- --=-QU9gGQmVx5cG5PtPBIoB--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1208018626.10093.7.camel>