Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 609522 - =sci-misc/boinc-7.6.33-r3: Sandbox Violation
Summary: =sci-misc/boinc-7.6.33-r3: Sandbox Violation
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Sven Eden
URL:
Whiteboard:
Keywords:
: 632350 (view as bug list)
Depends on: 580208
Blocks:
  Show dependency tree
 
Reported: 2017-02-16 12:03 UTC by Russell Knighton
Modified: 2017-09-30 15:32 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (build.log,323.29 KB, text/plain)
2017-02-16 12:03 UTC, Russell Knighton
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Russell Knighton 2017-02-16 12:03:28 UTC
Created attachment 463942 [details]
build.log

My installation of boinc is currently failing at the src_install stage with lots of the following errors:

X server found. dri2 connection failed! 
 * ACCESS DENIED:  open_wr:      /dev/dri/renderD128
open("/dev/dri/card0", O_RDWR) failed: Permission denied
Device open failed, aborting...

F: open_wr
S: deny
P: /dev/dri/renderD128
A: /dev/dri/renderD128
R: /dev/dri/renderD128
C: convert /var/tmp/portage/sci-misc/boinc-7.6.33-r3/distdir/boinc.tif -resize 16x16 /var/tmp/portage/sci-misc/boinc-7.6.33-r3/work/boinc_16.png

This is simply because my installation of media-gfx/imagemagick is built with the 'opencl' useflag, and of course 'convert' is trying to open the DRM devices causing the access violations.
Comment 1 Russell Knighton 2017-02-16 12:56:35 UTC
So, I've tried patching it myself with the following:

--- /usr/portage/sci-misc/boinc/boinc-7.6.33-r3.ebuild	2017-02-11 19:45:50.000000000 +0000
+++ boinc-7.6.33-r3.ebuild	2017-02-16 12:50:27.296737072 +0000
@@ -92,6 +92,25 @@
 	eautoreconf
 
 	use X && need-wxwidgets unicode
+
+	# For convert, when built with opencl
+	if use X; then
+		shopt -s nullglob
+		mesa_cards=$(echo -n /dev/dri/card* | sed 's/ /:/g')
+		if test -n "${mesa_cards}"; then
+			addpredict "${mesa_cards}"
+		fi
+		intel_cards=$(echo -n /dev/dri/render* | sed 's/ /:/g')
+		if test -n "${intel_cards}"; then
+			addpredict "${intel_cards}"
+		fi
+		ati_cards=$(echo -n /dev/ati/card* | sed 's/ /:/g')
+		if test -n "${ati_cards}"; then
+			addpredict "${ati_cards}"
+		fi
+		shopt -u nullglob
+		addpredict /dev/nvidiactl
+	fi
 }
 
 src_configure() {

I based that on what's already used in the imagemagick ebuild, but I had to add the Intel Beignet lines (as that's what is actually used on my system).

This worked and the installation has completed successfully, but I still had the following repeated messages shown:
X server found. dri2 connection failed! 
open("/dev/dri/card0", O_RDWR) failed: Permission denied
Device open failed, aborting...
X server found. dri2 connection failed! 
open("/dev/dri/card0", O_RDWR) failed: Permission denied
Device open failed, aborting...
cl_get_gt_device(): error, unknown device: ffffffff

I suppose actually I should have sued addwrite instead of addpredict? Would that be acceptable in an ebuild?
Comment 2 Sven Eden 2017-06-01 12:11:58 UTC
(In reply to Russell Knighton from comment #0)
> This is simply because my installation of media-gfx/imagemagick is built
> with the 'opencl' useflag, and of course 'convert' is trying to open the DRM
> devices causing the access violations.

Sorry for the late reply. I have had a rough private live in spring and forgot about that bug.

I'll see what happens if I add the opencl USE flag to imagemagick, and how to deal with it.
Comment 3 Sven Eden 2017-06-02 12:06:26 UTC
I can reproduce this and am working on a solution.
Comment 4 Sven Eden 2017-06-08 05:04:14 UTC
Actually this is not inside the responsibility of the ebuild. At least not as far as I understand the usage of convert[opencl] in a sandboxed environment.

The imagemagick ebuild generates /etc/sandbox.d/99imagemagick with:

--------
 ~ # cat /etc/sandbox.d/99imagemagick
SANDBOX_PREDICT="/dev/nvidiactl:/dev/ati/card:/dev/dri/card"
--------

If I enable my nvidia card (optimus laptop using bumblebee), then I can reproduce the error, although it is /dev/nvidia-uvm that gets complained about.

If I change the sandbox prediction file to

--------
 ~ # cat /etc/sandbox.d/99imagemagick
SANDBOX_PREDICT="/dev/nvidiactl:/dev/nvidia-uvm:/dev/ati/card:/dev/dri/card"
--------

The install goes fine.

I reckon the imagemagick ebuild should add the (at least two) missing devices there.

According to your error, the sandbox prediction written by the imagemagick ebuild should (or might) better read:

--------
 ~ # cat /etc/sandbox.d/99imagemagick
SANDBOX_PREDICT="/dev/nvidiactl:/dev/nvidia-uvm:/dev/ati/card:/dev/dri/card:/dev/dri/renderD128"
--------

I'll open a bug for that and reference this one.

The question will be, whether it is always /dev/dri/renderD128, or whether other devices will produce other device nodes?
Comment 5 Sven Eden 2017-06-08 05:11:24 UTC
Interestingly portage fills up the sandbox prediction to:

--------
 ~ # grep SANDBOX_PREDICT /home/portage/sci-misc/boinc-7.6.33-r4/temp/environment
declare -x SANDBOX_PREDICT="/dev/ati/card:/dev/crypto:/dev/dri/card:
/dev/dri/render:/dev/nvidia:/dev/nvidia-uvm:/dev/nvidiactl:/dev/random:
/home/portage/sci-misc/boinc-7.6.33-r4/homedir:/proc/self/coredump_filter:
/var/cache/fontconfig"
--------

I have a /dev/dri/renderD128 device, too. But I do not get any error when trying to install using the HD chipset.
Comment 6 Sven Eden 2017-06-08 07:22:35 UTC
It seems the issue is already known. See bug 580208
Comment 8 Sven Eden 2017-09-30 15:32:32 UTC
*** Bug 632350 has been marked as a duplicate of this bug. ***