freedomofpress
Issue when converting any documents: ‘’Unspecified error‘’
When converting any documents with Dangerzone 0.7.0 under Fedora 40, I always get the same error message “Unspecified error”. There is probably no connection, even if the error message is the same, right?
Originally posted by @sudwhiwdh in https://github.com/freedomofpress/dangerzone/issues/865#issuecomment-2233483704
@apyrgio
user@fedora:~$ dangerzone [DEBUG] Inferred system color scheme as OSColorMode.LIGHT [DEBUG] Setting up Dangerzone updater [DEBUG] Consulting updater settings before checking for updates [DEBUG] Checking platform type [DEBUG] Running on Linux, disabling updates [DEBUG] Will not check for updates, based on updater settings [INFO] Assigning ID 'CN6qpe' to doc '/home/user/Downloads/test.pdf' [DEBUG] Removing all documents [DEBUG] Marking doc CN6qpe as 'converting' [INFO] > /usr/bin/podman run --log-driver none --security-opt no-new-privileges --cap-drop all --cap-add SYS_CHROOT --network=none -u dangerzone --rm -i --name dangerzone-doc-to-pixels-CN6qpe --userns nomap dangerzone.rocks/dangerzone /usr/bin/python3 -m dangerzone.conversion.doc_to_pixels [ERROR] [doc CN6qpe] 0% Unspecified error [DEBUG] Marking doc CN6qpe as 'failed'
Thanks for the report! Let's dig deeper. Could you run the command you see in the logs, and some variations of it, and paste here (or in https://gist.github.com) the output please?
Original:
/usr/bin/podman run --log-driver none --security-opt no-new-privileges --cap-drop all --cap-add SYS_CHROOT --network=none -u dangerzone --rm -i --name dangerzone-doc-to-pixels-CN6qpe --userns nomap dangerzone.rocks/dangerzone /usr/bin/python3 -m dangerzone.conversion.doc_to_pixels
Variation 1 - Let's add some gVisor logging (-e RUNSC_DEBUG=1):
/usr/bin/podman run -e RUNSC_DEBUG=1 --log-driver none --security-opt no-new-privileges --cap-drop all --cap-add SYS_CHROOT --network=none -u dangerzone --rm -i --name dangerzone-doc-to-pixels-CN6qpe --userns nomap dangerzone.rocks/dangerzone /usr/bin/python3 -m dangerzone.conversion.doc_to_pixels
Variation 2 - Let's also add a different seccomp profile (--security-opt seccomp=/usr/share/dangerzone/seccomp.gvisor.json):
/usr/bin/podman run -e RUNSC_DEBUG=1 --security-opt seccomp=/usr/share/dangerzone/seccomp.gvisor.json --log-driver none --security-opt no-new-privileges --cap-drop all --cap-add SYS_CHROOT --network=none -u dangerzone --rm -i --name dangerzone-doc-to-pixels-CN6qpe --userns nomap dangerzone.rocks/dangerzone /usr/bin/python3 -m dangerzone.conversion.doc_to_pixels
Variation 3 - Let's remove the strict user namespace mapping (--userns nomap):
/usr/bin/podman run -e RUNSC_DEBUG=1 --security-opt seccomp=/usr/share/dangerzone/seccomp.gvisor.json --log-driver none --security-opt no-new-privileges --cap-drop all --cap-add SYS_CHROOT --network=none -u dangerzone --rm -i --name dangerzone-doc-to-pixels-CN6qpe dangerzone.rocks/dangerzone /usr/bin/python3 -m dangerzone.conversion.doc_to_pixels
Finally, can you give us the output of:
cat /etc/sub*id
(feel free to change the username in the output to user)
Thanks for the help!
There is quite a lot of output. Is there any sensitive information about my system that I should make unrecognisable before I copy it here?
p.s. What is the advantage of using https://gist.github.com/?
Good question: The logs are taken from within the Dangerzone container, so they should not contain any information about your host. In practice though, there are stuff that may leak (probably Linux kernel version).
But we don't have to do it this way. You could perhaps let me know if any of the above podman run commands succeeded or not. By succeed, I mean if they kept running in your machine, and you had to stop them with Ctrl-C. If they failed, may be you could pass me the last 20 or so relevant lines.
As for https://gist.github.com, no particular reason for the suggestion. Another poster used that, and I figured it will be easy for people who already have a GitHub account, that's all.
As for https://gist.github.com/, no particular reason for the suggestion. Another poster used that, and I figured it will be easy for people who already have a GitHub account, that's all.
My guess without looking at how this works: Probably the point is that the issues don't look cluttered with long log excerpts and remain readable.
The debug variations all abort with ‘gVisor quit with exit code: 128’
What does cat /etc/sub*id do?
My guess without looking at how this works: Probably the point is that the issues don't look cluttered with long log excerpts and remain readable.
Oh right, it's a Pastebin equivalent, if that's what you're asking. You can add long chunks of text there, and keep the rest of the issue tidy.
The debug variations all abort with ‘gVisor quit with exit code: 128’
Weeeird. Guess I have to start a Fedora 40 VM and take a look. Expect more follow-up next week for that.
What does cat /etc/sub*id do?
In my Fedora 40 container, it does the following:
$ cat /etc/sub*id
user:2000:2000
user:2000:2000
Basically it lists the contents of the /etc/subgid and /etc/subuid files. These files contain the mappings between user/group IDs in the host and the container. If the mapping range is too small, this may be a cause for problems. Privacy-wise, the only identifying part is the username (hence why I suggested renaming it to user)
Ok, that's the default configuration I believe, so we're good. I'll dig deeper and let you know. Thanks for the info!
Ok, that's the default configuration I believe, so we're good. I'll dig deeper and let you know. Thanks for the info!
Thank you and have a nice weekend!
$ cat /etc/sub*id user:2000:2000 user:2000:2000
Your range looks completely different. Simply a different configuration?
I managed to install Fedora 40 in a VM, and reproduced the issue you're seeing @sudwhiwdh. The root cause of this error is that Dangerzone 0.7.0 does not work with SELinux in enforcing mode. This is evident if you check your journalctl entries for audit logs, where you'll find a line like this:
Jul 25 17:51:56 10.0.2.15 audit[8164]: AVC avc: denied { mounton } for pid=8164 comm="exe" path="/proc/fs" dev="proc" ino=4026531847 scontext=system_u:system_r:container_t:s0:c139,c177 tcontext=system_u:object_r:proc_t:s0 tclass=dir permissive=0
This is triggered by gVisor running within Podman, when it tries to mount /proc to a different location:
$ /usr/bin/podman run -e RUNSC_DEBUG=1 --log-driver none --security-opt no-new-privileges --cap-drop all --cap-add SYS_CHROOT --network=none -u dangerzone --rm -i --name dangerzone-doc-to-pixels-qyU8c4 --userns nomap dangerzone.rocks/dangerzone /usr/bin/python3 -m dangerzone.conversion.doc_to_pixels
8< ... snip ... >8
I0725 14:19:04.811776 20 main.go:197] **************** gVisor ****************
I0725 14:19:04.812445 20 boot.go:258] Setting product_name: "Standard PC (Q35 + ICH9, 2009)"
W0725 14:19:04.813081 20 specutils.go:129] noNewPrivileges ignored. PR_SET_NO_NEW_PRIVS is assumed to always be set.
I0725 14:19:04.813105 20 chroot.go:91] Setting up sandbox chroot in "/tmp"
W0725 14:19:04.813312 20 chroot.go:108] Failed to copy /etc/localtime: open /etc/localtime: no such file or directory. UTC timezone will be used.
I0725 14:19:04.813335 20 chroot.go:36] Mounting "/proc" at "/tmp/proc"
W0725 14:19:04.813394 20 util.go:64] FATAL ERROR: error setting up chroot: error remounting chroot in read-only: permission denied
error setting up chroot: error remounting chroot in read-only: permission denied
D0725 14:19:04.814640 7 sandbox.go:1278] Destroying sandbox "dangerzone"
D0725 14:19:04.814726 7 sandbox.go:1287] Killing sandbox "dangerzone"
D0725 14:19:04.814809 7 container.go:776] Destroy container, cid: dangerzone
D0725 14:19:04.814847 7 container.go:1087] Killing gofer for container, cid: dangerzone, PID: 15
W0725 14:19:04.814928 7 util.go:64] FATAL ERROR: running container: creating container: cannot create sandbox: cannot read client sync file: waiting for sandbox to start: EOF
running container: creating container: cannot create sandbox: cannot read client sync file: waiting for sandbox to start: EOF
W0725 14:19:04.815004 7 main.go:227] Failure to execute command, err: 1
gVisor quit with exit code: 128
I'll open a separate issue to explain that Dangerzone needs to create containers with no SELinux labels, since they break nested containerization. In the meantime, a workaround is to set SELinux to permissive mode:
sudo setenforce Permissive
It's not ideal, but we'll push new RPMs out soon. Thanks again for the bug report!
Hey @sudwhiwdh. I'm happy to report that we have a fix out for Fedora systems. For an explanation about the fix and our solution, you can check out https://github.com/freedomofpress/dangerzone/issues/880. tl;dr: we managed to make Dangerzone work with SELinux in enforcing mode, without disabling SELinux for the Podman container that we spawn.
You should be able to install this fix with dnf update. If it works for you, we can close this issue.
Hi @sudwhiwdh. I haven't heard back from you, but hopefully the new Dangerzone update should resolve this issue. I'm closing this issue now, but feel free to reopen it if something else has come up. Thanks again for your bug report!
@apyrgio I would like to give you some feedback. The update went without any problems and since the update I can use Dangerzone again. Thank you very much for looking into this issue!
I'll open a separate issue to explain that Dangerzone needs to create containers with no SELinux labels, since they break nested containerization. In the meantime, a workaround is to set SELinux to permissive mode:
sudo setenforce Permissive
I have not tested this workaround as I am not familiar with SELinux settings.
Hi @sudwhiwdh. As @apyrgio isn't around this week I'm taking the relay. Thanks for opening this issue and keep us informed about how this worked for you.
I have not tested this workaround as I am not familiar with SELinux settings.
Don't worry, this has been covered by #880 and if the upgrade works it means the fix did the job! :partying_face:
