Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

OpenSSL accesses /dev/crypto on BSDs, which is incorrectly marked as predicted
access in src_test (and it contains a typo) in all versions on portage tree.
Testing FreeBSD patch for sandbox revealed this inconsistency, causing access
denied violations.

Steps to reproduce:

1. Apply FreeBSD experimental patches to sandbox
(http://unleashed.amule.org/soc)
2. Enable FEATURES="sandbox"
3. emerge openssl

Actual results:

Sandbox denies accesses to /dev/crypto and errors out preventing OpenSSL from
emerging.

Expected results:

Sandbox denies accesses to /dev/crypto _but_ as they're predicted all goes fine
and OpenSSL gets emerged.

Proposed patch to follow.

Created an attachment (id=90353) [details]
Patch to fix addpredict in OpenSSL ebuilds

This patch should apply to all versions and fixes the problem for 0.9.7j
specifically.

Last time we decided it was up to sandbox allow access to /dev/crypto, it's
just a conditional to add to the code.

Woops, okay, didn't have info on that topic. I'll patch sandbox to always
autopredict access to /dev/crypto and include it on my tree. Thanks.

Now change the request to kill that add_predict line which is wrong anyways.

As its only a FreeBSD issue, it really should only add the predict for FreeBSD,
and I do not want to hardcode any more path's.  For the access that stuff
builing or using OpenSSL during build need, it should add a /etc/sandbox.d/
file that allows/predict's this.  I know its not yet in an unmasked or stable
release of sandbox, but then aparently all versions sandbox still have issues
on BSD.

(In reply to comment #4)
> For the access that stuff
> builing or using OpenSSL during build need, it should add a /etc/sandbox.d/
> file that allows/predict's this.

PS, only installed on FreeBSD as well ...

yeah i dont think this is something to add to sandbox

last i heard this was only an issue in src_test

Looks like this only applies to OpenSSL on BSD and I haven't found any other
ebuild requiring /dev/crypto to be predicted. If that is the case, why not
apply the proposed patch and be done with it (which, btw, doesn't predict
/dev/crypto under src_test)?

If not, I guess I should patch sandbox to install a file under /etc/sandbox.d
when built for G/FBSD (which looks to me as too much for just one ebuild ATM).
Would that be okay?

(In reply to comment #7)
> Looks like this only applies to OpenSSL on BSD and I haven't found any other
> ebuild requiring /dev/crypto to be predicted. If that is the case, why not
> apply the proposed patch and be done with it (which, btw, doesn't predict
> /dev/crypto under src_test)?
> 

Agreed, if its only needed for OpenSSL to build, there is no reason for it to
be in /etc/sandbox.d/.  Just fix the ebuild.

i'm not inclined to apply patches that look broken to me

/dev/crypto is used only at runtime, not at compile time ... so why is
addpredict needed anywhere but src_test ?

(In reply to comment #9)
> i'm not inclined to apply patches that look broken to me
> 
> /dev/crypto is used only at runtime, not at compile time ... so why is
> addpredict needed anywhere but src_test ?

Because actual sandbox violations happen in src_compile and src_install but not
in src_test. Fact is those two stages enter a "Doing certs" phase in which they
try to write to /dev/crypto. If this is expected behaviour or not, I don't
know. Maintainers may have something to say about this.

Okay, so since freebsd-lib-6.2_beta2 I'm now installing a sandbox configuration
file, that allows access to /dev/crypto, which means this bug can be closed.