drawio command-line requires setuid and network namespace manipulation

[kanaka]

This is a sub-task of #127.

I'm trying to package draw.io into a docker container for easy command-line export usage. However, drawio requires elevated permissions even when used for command-line export that make it inconvenient to use with docker. Here is what happens when it is run from a docker container:

docker run -it drawio-image drawio -x --crop infile.drawio -o outfile.pdf
[10:0810/023136.363143:FATAL:setuid_sandbox_host.cc(157)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /opt/draw.io/chrome-sandbox is owned by root and has mode 4755.

Add the setuid bit to the chrome-sandbox isn't sufficient. Doing so results in a different permissions error:

docker run -it drawio-image drawio -x --crop infile.drawio -o outfile.pdf
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted
Trace/breakpoint trap (core dumped)

The workaround is to run with SYS_ADMIN kernel capabilities (setuid bit is not needed in this case):

docker run -it --cap-add SYS_ADMIN drawio-image drawio -x --crop infile.drawio -o outfile.pdf
Home directory not accessible: Permission denied
imgs/symbol_alt.drawio -> imgs/symbol_alt.pdf

Requiring elevated privileges to do export on the command-line is probably counter productive to security and certainly makes using it with docker annoying.

[scy]

Since the draw.io application uses Electron, it’s basically wrapped in Chrome and it’s Chrome that requires this permission. However, there’s the --no-sandbox flag to Chrome that disables sandboxing, which is bad for security, but skips the namespace move.

I managed to run drawio inside of an unprivileged Docker container like so: xvfb-run drawio --no-sandbox -V. In my setup, draw.io is supposed to export to SVG while running in a GitLab CI pipeline, which means adding permissions to the container is not an option for me.

However, while displaying the version (with -V) works, requesting an export with -x simply causes the application to freeze. It uses no CPU, it’s simply idling, apparently. I have to use Ctrl-C to stop it. No output is generated.

That doesn’t have anything to do with this issue right here though.

[davidjgraph]

Note we've improved the docker images of both draw.io and the Node base image export back-end that we use in the online version.

The initial instructions are at https://github.com/jgraph/drawio/blob/master/etc/docker/README.md and the image export docker stuff at https://github.com/jgraph/docker-drawio/tree/master/image-export.

I think that is better suited to being a docker image, so I'd rather apply effort at giving that the API needed than fixing this issue.

[scy]

@davidjgraph Thanks, I managed to have the standalone export server running in a matter of minutes, which is awesome! 👍 (The API docs are a bit confusing though.) However, I’d love to be able to export to SVG instead of PDF, because (as far as I can see) SVGs ignore the drawing canvas and are auto-cropped to just the contents, PDFs are not. This makes it easier to embed them into my LaTeX document(s), without having to think in advance about how big the drawing is supposed to be (in the final document) while I’m drawing.

I might find a way to auto-crop PDFs or extract just the drawing, but this feels more of a hassle than having SVG export in the first place.

Or do you have any other suggestions?

[scy]

Well, this really doesn’t belong into this ticket, but in case anyone else tries to do something similar:

I’m now using pdfcrop (package texlive-extra-utils in Ubuntu) to automatically crop down a PDF to the size of its contents. It can even work on stdin, so in order to generate a cropped PDF directly from a draw.io file, you can do:

curl --data 'format=pdf' --data-urlencode 'xml@my-drawing.drawio' http://localhost:8000/ | pdfcrop - my-drawing.pdf

(Assuming you have the standalone export server running on port 8000 and an input image in draw.io’s XML format in my-drawing.drawio in the current directory.)

Works good enough for me, thanks! 😉

[rickyjames35]

Was there a solution to being able to run drawio in a docker container? I'm trying to use sphinxcontrib-drawio as part of my CI but this all runs on in a docker container and I'm getting the Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted error.

[scy]

@rickyjames35 I didn’t find any solution. As I said in #144 (comment), running drawio in xvfb in a container with --no-sandbox works if you just want to display the drawio version (😏) but not for any real work. Maybe it’s possible to get to a solution from there with some time and effort.