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.
Please search. *** This bug has been marked as a duplicate of bug 135745 ***
The .lst violation appears to be something else and specific to ipw3945. Reopening.
emerging ipw3945 (1.2.0 and 1.2.2) results in a sandbox error: "open_wr: /usr/src/linux-2.6.23/.lst"
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.
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
Maybe can anybody else take care of this bug?!
I am not affected by any sandbox violation using kernel-2.6.22 instead :-/
(In reply to comment #7) > I am not affected by any sandbox violation using kernel-2.6.22 instead :-/ > But 2.6.23.
(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... ;-)
Also seeing this with ipw3945-1.2.1 and hardened-sources-2.6.23-r1.
Created attachment 135974 [details, diff] ipw3945-1.2.2.ebuild.diff Fixups.
Created attachment 135976 [details, diff] ipw3945-1.2.2-build.patch
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.
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.
(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.
(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.
(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.
(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.
(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.
ty, fixed
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?
(Reopening for 1.2.0)
Let's make 1.2.22 stable instead (discussion for this is in bug 197806).
