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 attachment 90353 [details, diff] 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.
