Bugzilla Bug 195137

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 an attachment (id=135974) [details]
ipw3945-1.2.2.ebuild.diff

Fixups.

Created an attachment (id=135976) [details]
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).