195137 2007-10-08 19:20 0000 net-wireless/ipw3945-1.2.2: sandbox access violation on emerge 2007-12-05 16:38:37 0000 1 1 1 Unclassified Gentoo Linux Unspecified unspecified x86 Linux RESOLVED FIXED P2 normal --- 197806 1 0xdeadbeef@pobox.com lack@gentoo.org alonbl@gentoo.org blackace@gentoo.org dang@gentoo.org danost@gmail.com doron.fediuck@gmail.com hydonsingore@educities.edu.tw j.romildo@gmail.com jkt@gentoo.org mobile@gentoo.org njdoyle+bugs@gmail.com pacho@condmat1.ciencias.uniovi.es public@mroot.net r_a@lavabit.com throw_away_2002@yahoo.com 0xdeadbeef@pobox.com 2007-10-08 19:20:22 0000 emerge of ipw3945 fails with a sandbox access violation. It is apparently trying to write some stuff in /usr/src/linux/ Reproducible: Always Steps to Reproduce: 1. emerge ipw3945 Actual Results: --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/var/log/sandbox/sandbox-net-wireless_-_ipw3945-1.2.2-15069.log" open_wr: /usr/src/linux-2.6.23-rc9/null.gcda open_wr: /usr/src/linux-2.6.23-rc9/null.gcda open_wr: /usr/src/linux-2.6.23-rc9/null.gcda open_wr: /usr/src/linux-2.6.23-rc9/null.gcda open_wr: /usr/src/linux-2.6.23-rc9/.lst open_wr: /usr/src/linux-2.6.23-rc9/.lst open_wr: /usr/src/linux-2.6.23-rc9/null.gcda -------------------------------------------------------------------------------- Expected Results: Emerge successful! I see the same behaviour in 1.2.0 also. I can work around this problem by running ebuild directly. jakub@gentoo.org 2007-10-08 19:22:12 0000 Please search. *** This bug has been marked as a duplicate of bug 135745 *** dsd@gentoo.org 2007-10-24 20:11:51 0000 The .lst violation appears to be something else and specific to ipw3945. Reopening. r_a@lavabit.com 2007-10-24 21:02:21 0000 emerging ipw3945 (1.2.0 and 1.2.2) results in a sandbox error: "open_wr: /usr/src/linux-2.6.23/.lst" ckyoog@gmail.com 2007-10-25 03:49:28 0000 Bug 135745 had marked as fixed, so I asked here. Now, is there somebody to be resolving the problem of ipw3945 sandbox violation? Please help us. Thanks. Don't leave it or take long time to solve it as bug 135745. Thanks again. michel77@gmail.com 2007-10-25 12:15:04 0000 the same here ACCESS VIOLATION on compiling ipw3945 on 2.6.23er kernel ... FEATURES="-sandbox" emerge -av ipw3945 is the only known possibility to compile michel77@gmail.com 2007-10-29 12:38:31 0000 Maybe can anybody else take care of this bug?! pacho@condmat1.ciencias.uniovi.es 2007-11-01 19:28:46 0000 I am not affected by any sandbox violation using kernel-2.6.22 instead :-/ ckyoog@gmail.com 2007-11-05 02:40:37 0000 (In reply to comment #7) > I am not affected by any sandbox violation using kernel-2.6.22 instead :-/ > But 2.6.23. pacho@condmat1.ciencias.uniovi.es 2007-11-05 20:19:16 0000 (In reply to comment #8) > (In reply to comment #7) > > I am not affected by any sandbox violation using kernel-2.6.22 instead :-/ > > > But 2.6.23. > Yes, I see... ;-) blackace@gentoo.org 2007-11-11 20:11:49 0000 Also seeing this with ipw3945-1.2.1 and hardened-sources-2.6.23-r1. alonbl@gentoo.org 2007-11-14 17:34:43 0000 Created an attachment (id=135974) ipw3945-1.2.2.ebuild.diff Fixups. alonbl@gentoo.org 2007-11-14 17:35:13 0000 Created an attachment (id=135976) ipw3945-1.2.2-build.patch jkt@gentoo.org 2007-11-22 23:49:10 0000 The attached patch looks sane to me and indeed fixes the issue with denied write, both with USE=debug and without it. The wireless interface also seems to work. Re-assigning to proper maintainers. ckyoog@gmail.com 2007-11-23 17:51:08 0000 The patch seems to fix the problem to me. That's good. Now I can use 2.6.23 with wireless. Hope the patch will be added in new version ipw3945. jkt@gentoo.org 2007-11-24 09:36:35 0000 (In reply to comment #14) > The patch seems to fix the problem to me. That's good. Now I can use 2.6.23 > with wireless. Hope the patch will be added in new version ipw3945. Strictly speaking, nothing ever prevented you from using it. You only had to merge it with sandbox disabled (as suggested in comment #5 and in the other bug), which might be inconvenient, but works. alonbl@gentoo.org 2007-11-24 10:26:43 0000 (In reply to comment #15) > Strictly speaking, nothing ever prevented you from using it. You only had to > merge it with sandbox disabled (as suggested in comment #5 and in the other > bug), which might be inconvenient, but works. You cannot expect a user to disable sandbox as his system may be compromised. Also, you cannot expect a user to follow none gentoo developer recommendation regarding so risky issue. Also, please note that the current ebuild does not handle the debug correctly at all, resulting in enabling it when requested to disable. The current ebuild is a mess. Please don't recommend user to use it. jkt@gentoo.org 2007-11-24 10:38:30 0000 (In reply to comment #16) > You cannot expect a user to disable sandbox as his system may be compromised. Note that ebuild can always use RESTRICT=sandbox or a similar method to completely nuke user's system. Sandbox isn't a security method that guarantees that ebuilds behave correctly, it just prevents some stupid mistakes on a programmer's side. Could we please move any further sandbox-related comments to the gentoo-dev ML, which is IMHO more apropriate? > The current ebuild is a mess. Please don't recommend user to use it. Thanks for your patch. alonbl@gentoo.org 2007-11-24 10:52:41 0000 (In reply to comment #17) > Note that ebuild can always use RESTRICT=sandbox or a similar method to > completely nuke user's system. I am *REALLY* hopping you don't have *ANY* package with this restriction. > Sandbox isn't a security method that guarantees > that ebuilds behave correctly, it just prevents some stupid mistakes on a > programmer's side. Could we please move any further sandbox-related comments to > the gentoo-dev ML, which is IMHO more apropriate? This is my final note about this... sandbox *IS* a security method, as if one ebuild modify the root, second ebuild may also be effected, thus all your system modifies its behavior. Thanks. jkt@gentoo.org 2007-11-24 11:06:36 0000 (In reply to comment #18) > This is my final note about this... sandbox *IS* a security method, as if one > ebuild modify the root, second ebuild may also be effected, thus all your > system modifies its behavior. Point that I've been trying to make here is that sandbox can be circumvented extremely easy. This means that you couldn't say "I use sandbox, hence my ebuilds can't overwrite important parts of my live filesystem". Examples about legitimate cases that disable sandbox and access user's filesystem can be found in the enewuser/enewgroup functions in eutils.eclass. genstef@gentoo.org 2007-11-25 22:01:36 0000 ty, fixed gentoo@ttuttle.net 2007-12-05 16:03:13 0000 Can you please patch the ipw3945-1.2.0 ebuild in a similar way, as it is the latest stable ipw3945 and suffers from the same problem? gentoo@ttuttle.net 2007-12-05 16:03:32 0000 (Reopening for 1.2.0) jkt@gentoo.org 2007-12-05 16:38:37 0000 Let's make 1.2.22 stable instead (discussion for this is in bug 197806). 135974 2007-11-14 17:34 0000 ipw3945-1.2.2.ebuild.diff ipw3945-1.2.2.ebuild.diff text/plain SW5kZXg6IGlwdzM5NDUtMS4yLjIuZWJ1aWxkCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC92YXIvY3Zz cm9vdC9nZW50b28teDg2L25ldC13aXJlbGVzcy9pcHczOTQ1L2lwdzM5NDUtMS4yLjIuZWJ1aWxk LHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjMKZGlmZiAtdSAtQiAtcjEuMyBpcHczOTQ1LTEuMi4y LmVidWlsZAotLS0gaXB3Mzk0NS0xLjIuMi5lYnVpbGQJMTEgU2VwIDIwMDcgMTU6NDg6NDUgLTAw MDAJMS4zCisrKyBpcHczOTQ1LTEuMi4yLmVidWlsZAkxNCBOb3YgMjAwNyAxNzozMjo0OCAtMDAw MApAQCAtNDIsNiArNDIsMTMgQEAKIAlsaW51eC1tb2RfcGtnX3NldHVwCiAKIAlCVUlMRF9QQVJB TVM9IktTUkM9JHtLVl9ESVJ9IEtTUkNfT1VUUFVUPSR7S1ZfT1VUX0RJUn0gU0hFTEw9L2Jpbi9i YXNoIgorCUJVSUxEX1BBUkFNUz0iJHtCVUlMRF9QQVJBTVN9IFQ9JHtUfSIKKwlCVUlMRF9QQVJB TVM9IiR7QlVJTERfUEFSQU1TfSBDT05GSUdfSVBXMzk0NV9NT05JVE9SPXkgQ09ORklHX0lFRUU4 MDIxMV9SQURJT1RBUD15IENPTkZJR19JUFczOTQ1X1BST01JU0NVT1VTPXkiCisJaWYgdXNlIGRl YnVnOyB0aGVuCisJCUJVSUxEX1BBUkFNUz0iJHtCVUlMRF9QQVJBTVN9IENPTkZJR19JUFczOTQ1 X0RFQlVHPXkiCisJZWxzZQorCQlCVUlMRF9QQVJBTVM9IiR7QlVJTERfUEFSQU1TfSBDT05GSUdf SVBXMzk0NV9ERUJVRz1uIgorCWZpCiAKIAkjIHVzZXJzIGRvbid0IHJlYWQgdGhlIENoYW5nZUxv ZyBhbmQgd29uZGVyIHdoeSB0aGUga2VybmVsIGNoZWNrIGZhaWxzCiAJIyAoMSkgY2hlY2sgaWYg dGhlIGtlcm5lbCBkaXIgKC91c3Ivc3JjL2xpbnV4KSBpcyBtaXNzaW5nIGllZWU4MDIxMQpAQCAt NjQsMTQgKzcxLDggQEAKIAogc3JjX3VucGFjaygpIHsKIAl1bnBhY2sgJHtQL19wcmUvLXByZX0u dGd6Ci0KIAljZCAiJHtTfSIKLQllcGF0Y2ggIiR7RklMRVNESVJ9Ii8ke1BOfS0xLjIuMC1NYWtl ZmlsZS5wYXRjaAotCi0JaWYgdXNlIGRlYnVnIDsgdGhlbgotCQlzZWQgLWkgLWUgInM6XlwoQ09O RklHX0lQVzM5NDVfREVCVUdcKT0uKjpcMT15OiIgIiR7U30iL01ha2VmaWxlIHx8IFwKLQkJCWRp ZSAiRmFpbGVkIHRvIGVuYWJsZSBkZWJ1Z2dpbmcgc3VwcG9ydCEiCi0JZmkKKwllcGF0Y2ggIiR7 RklMRVNESVJ9LyR7UH0tYnVpbGQucGF0Y2giCiB9CiAKIHNyY19pbnN0YWxsKCkgewo= 135976 2007-11-14 17:35 0000 ipw3945-1.2.2-build.patch ipw3945-1.2.2-build.patch text/plain ZGlmZiAtdXJOcCBpcHczOTQ1LTEuMi4yLm9yZy9NYWtlZmlsZSBpcHczOTQ1LTEuMi4yL01ha2Vm aWxlCi0tLSBpcHczOTQ1LTEuMi4yLm9yZy9NYWtlZmlsZQkyMDA3LTA0LTMwIDA2OjQ0OjU2LjAw MDAwMDAwMCArMDMwMAorKysgaXB3Mzk0NS0xLjIuMi9NYWtlZmlsZQkyMDA3LTExLTE0IDE5OjIz OjA3LjAwMDAwMDAwMCArMDIwMApAQCAtMTExLDcgKzExMSw3IEBAIElFRUU4MDIxMV9BUEkgOj0g JChzaGVsbCAkKERJUikvc25hcHNob3QKIEVYVFJBX0NGTEFHUyArPSAtRElQVzM5NDVfQ09NUEFU PSQoSUVFRTgwMjExX0FQSSkKIAogaWZlcSAoJChDT05GSUdfSVBXMzk0NV9ERUJVRykseSkKLQlF WFRSQV9DRkxBR1MgKz0gLWcgLVdhLC1hZGhsbXM9JEAubHN0CisJRVhUUkFfQ0ZMQUdTICs9IC1n IC1XYSwtYWRobG1zPSQoVCkvJEAubHN0CiBlbmRpZgogCiBpZmRlZiBLQlVJTERfRVhUTU9ECkBA IC0xOTMsMzQgKzE5Myw2IEBAIHV0aWxzOgogCUBbICEgLWQgdXRpbCBdIHx8IG1ha2UgLUMgdXRp bCBJRUVFODAyMTFfUEFUSD0kKElFRUU4MDIxMV9QQVRIKQogCiBjaGVja19pbmM6Ci0JQCggWyAi JChJRUVFODAyMTFfRFVQTElDQVRFKSIgXSAmJiBlY2hvIC1lIFwKLSJcbiBXQVJOSU5HOiBZb3Vy IGtlcm5lbCBjb250YWlucyBpZWVlODAyMTEgc3ltYm9sIGRlZmluaXRpb25zIGFuZCB5b3VcbiJc Ci0iYXJlIG5vdCB1c2luZyB0aGUga2VybmVsJ3MgZGVmYXVsdCBpZWVlODAyMTEgc3Vic3lzdGVt LiAgKFBlcmhhcHMgeW91XG4iXAotInVzZWQgdGhlIG91dC1vZi10cmVlIGllZWU4MDIxMSBzdWJz eXN0ZW0ncyAnbWFrZSBpbnN0YWxsJyBvciBoYXZlXG4iXAotInByb3ZpZGVkIGEgcGF0aCB0byB0 aGUgaWVlZTgwMjExIHN1YnN5c3RlbSB2aWEgSUVFRTgwMjExX0lOQy4pXG5cbiJcCi0iSWYgeW91 IHdpc2ggdG8gdXNlIHRoZSBvdXQtb2YtdHJlZSBpZWVlODAyMTEgc3Vic3lzdGVtIHRoZW4gaXQg aXNcbiJcCi0icmVjb21tZW5kZWQgdG8gdXNlIHRoYXQgcHJvamVjdHMnIFwibWFrZSBwYXRjaF9r ZXJuZWxcIiBmYWNpbGl0eVxuIlwKLSJhbmQgcmVidWlsZCB5b3VyIGtlcm5lbCB0byB1cGRhdGUg dGhlIE1vZHVsZSBzeW1ib2wgdmVyc2lvbiBpbmZvcm1hdGlvbi5cbiJcCi0iXG4iXAotIkZhaWx1 cmUgdG8gZG8gdGhpcyBtYXkgcmVzdWx0IGluIGJ1aWxkIHdhcm5pbmdzIGFuZCB1bmV4cGVjdGVk XG4iXAotImJlaGF2aW9yIHdoZW4gcnVubmluZyBtb2R1bGVzIHdoaWNoIHJlbHkgb24gdGhlIGll ZWU4MDIxMSBzdWJzeXN0ZW0uXG5cbiJcIHx8IFwKLQlleGl0IDApCi0KLQlAKCBbICIkKElFRUU4 MDIxMV9EVVBMSUNBVEUpIiBdICYmIFwKLQkgICBbICEgIiQoSUVFRTgwMjExX0lHTk9SRV9EVVBM SUNBVEUpIiBdICYmIGVjaG8gLWUgXAotIiBBYm9ydGluZyB0aGUgYnVpbGQuICBZb3UgY2FuIGZv cmNlIHRoZSBidWlsZCB0byBjb250aW51ZSBieSBhZGRpbmc6XG5cbiJcCi0iXHRJRUVFODAyMTFf SUdOT1JFX0RVUExJQ0FURT15XG5cbiJcCi0idG8geW91ciBtYWtlIGNvbW1hbmQgbGluZS5cblxu IiAmJiBleGl0IDEgfHwgZXhpdCAwKQotCi0JQCggWyAhICIkKElFRUU4MDIxMV9BUEkpIiBdICYm IGVjaG8gLWUgXAotIlxuIEVSUk9SOiBBIGNvbXBhdGlibGUgc3Vic3lzdGVtIHdhcyBub3QgZm91 bmQgaW4gdGhlIGZvbGxvd2luZyBwYXRoW3NdOlxuXG4iXAotIlx0JChJRUVFODAyMTFfUkVTKVxu XG4iXAotIllvdSBuZWVkIHRvIGluc3RhbGwgdGhlIGllZWU4MDIxMSBzdWJzeXN0ZW0gZnJvbSBo dHRwOi8vaWVlZTgwMjExLnNmLm5ldFxuIlwKLSJhbmQgcG9pbnQgdGhpcyBidWlsZCB0byB0aGUg bG9jYXRpb24gd2hlcmUgeW91IGluc3RhbGxlZCB0aG9zZSBzb3VyY2VzLCBlZy46XG5cbiJcCi0i XHQlIG1ha2UgSUVFRTgwMjExX0lOQz0vdXNyL3NyYy9pZWVlODAyMTEvXG5cbiJcCi0ib3IgdXNl IHRoZSAnbWFrZSBwYXRjaF9rZXJuZWwnIHdpdGhpbiB0aGUgaWVlZTgwMjExIHN1YnN5c3RlbSB0 byBwYXRjaCB5b3VyXG4iXAotImtlcm5lbCBzb3VyY2VzLlxuIiAmJiBleGl0IDEgfHwgZXhpdCAw KQotCiAJQGVjaG8gLWUgXAogIiBVc2luZyBpZWVlODAyMTEgc3Vic3lzdGVtIHZlcnNpb24gQVBJ IHYkKElFRUU4MDIxMV9BUEkpIGZyb206XG5cbiIgXAogIlx0QmFzZTogJChJRUVFODAyMTFfQkFT RSlcbiIgXApAQCAtMjQxLDcgKzIxMyw3IEBAIGNvZGluZ3N0eWxlOgogCiBjbGVhbjoKIAlAWyAh IC1kIHV0aWwgXSB8fCBtYWtlIC1DIHV0aWwgY2xlYW4gfHwgdHJ1ZQotCXJtIC1mICoue21vZC5j LG1vZCxvLGtvLHJlaixvcmlnfSAuKi57c3RhbXAsZmxhZ3MsY21kfSAubHN0ICoubHN0ICp+IAor CXJtIC1mICoue21vZC5jLG1vZCxvLGtvLHJlaixvcmlnfSAuKi57c3RhbXAsZmxhZ3MsY21kfSAk KFQpLy5sc3QgJChUKS8qLmxzdCAqfiAKIAlybSAtcmYgJChESVIpL3RtcCAkKERJUikvLnRtcF92 ZXJzaW9ucyBNb2R1bGUuc3ltdmVycyBNb2R1bGVzLnN5bXZlcnMKIAlmb3IgZmlsZSBpbiAqLntj LGh9OyBkbyBcCiAJCXNlZCAtaSAtZSAiczpcICokJDo6ZyIgLWUgInM6XHQqJCQ6OmciICQkZmls ZTsgXAo=