Bug #16414

onionshare-gui does not start in VirtualBox (with VBoxVGA and 3D acceration enabled)

Added by scootergrisen 2019-01-31 22:31:32 . Updated 2019-04-03 13:28:39 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Tails_4.0
Start date:
2019-01-31
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
OnionShare
Deliverable for:

Description

Name of the affected software
——————————————-
onionshare-gui

Exact steps to reproduce the error
—————————————————
Start terminal
Type onionshare-gui + ENTER

Actual result and description of the error
—————————————————————
Traceback (most recent call last):
File “/usr/bin/onionshare-gui”, line 21, in
import onionshare_gui
File “/usr/lib/python3/dist-packages/onionshare_gui/init.py”, line 20, in
from .onionshare_gui import *
File “/usr/lib/python3/dist-packages/onionshare_gui/onionshare_gui.py”, line 22, in
from PyQt5 import QtCore, QtWidgets, QtGui
ImportError: libGL.so.1: failed to map segment from shared object

Desired result
———————
Show OnionShare window.

Works with VBoxSVGA and VMSVGA when 3D acceration is enabled but for some reason not VBoxVGA.

Se also https://github.com/micahflee/onionshare/issues/891

Tested with tails-amd64-3.12.iso in VirtualBox 6.0.

Subtasks

Related issues

Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

History

#1 Updated by mercedes508 2019-02-03 14:30:52

  • Assignee set to scootergrisen

Why don’t you just start onionshare from the application menu?

#2 Updated by scootergrisen 2019-02-03 22:12:30

OnionShare in the application menu runs onionshare-gui.

The .desktop file says:
> Exec=/usr/bin/onionshare-gui

If i select OnionShare in the application menu i see this with “sudo dmesg”:

> [ 879.075447] audit: type=1400 audit(1549231684.431:39): apparmor=“DENIED” operation=“file_mmap” profile=“/usr/bin/onionshare-gui” name=“/usr/lib/VBoxOGL.so” pid=11415 comm=“onionshare-gui” requested_mask=“m” denied_mask=“m” fsuid=1000 ouid=0

#3 Updated by Anonymous 2019-02-04 13:09:00

I won’t have time to look into this soon unfortunately. But putting it on my radar anyway.

#4 Updated by scootergrisen 2019-02-04 15:35:12

If you got some ideas on what i could try to get closed to what the problem might be i could try that in the mean time.

#5 Updated by intrigeri 2019-02-05 11:59:07

  • Subject changed from onionshare-gui dont want to start in VirtualBox (with VBoxVGA and 3D acceration enabled) to onionshare-gui does not start in VirtualBox (with VBoxVGA and 3D acceration enabled)
  • Status changed from New to Confirmed
  • Assignee changed from scootergrisen to intrigeri
  • Target version set to Tails_3.13

This seems to be a bug in the AppArmor profile we ship. It seems it’s been upstreamed but is not shipped in the Debian package yet (see Feature #11929#note-15) so let’s fix it on our side for now. I’ll check if the problem is in an abstraction.

#6 Updated by intrigeri 2019-02-05 11:59:17

  • related to Feature #11929: Upstream AppArmor profiles for Onionshare added

#7 Updated by intrigeri 2019-02-05 11:59:45

#8 Updated by intrigeri 2019-02-13 15:15:57

Reproduced.

#9 Updated by intrigeri 2019-02-16 06:28:15

At first glance, it looks like /etc/apparmor.d/abstractions/base expects all shared libraries to be called lib*.so, while this one is called VBoxOGL.so.

#10 Updated by intrigeri 2019-02-16 06:32:23

  • related to deleted (Feature #11929: Upstream AppArmor profiles for Onionshare)

#11 Updated by intrigeri 2019-02-24 17:12:10

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

Asked on https://gitlab.com/apparmor/apparmor/merge_requests/345 why the policy is the way it is.

#12 Updated by intrigeri 2019-03-11 09:32:49

  • Target version changed from Tails_3.13 to Tails_3.14

Pinged on the upstream discussion. I don’t expect we’ll reach a conclusion that we can implement in time for 3.13.

#13 Updated by intrigeri 2019-03-20 14:45:21

#14 Updated by intrigeri 2019-03-20 14:45:42

  • blocked by deleted (Feature #15507: Core work 2019Q1: Foundations Team)

#15 Updated by intrigeri 2019-03-24 06:18:41

  • % Done changed from 10 to 20

It seems that consensus was reached upstream. I’d rather resolve the conflicts of the proposed fix with our config/chroot_local-patches/apparmor-aliases.diff only once, so my plan is:

  1. get this merged upstream
  2. apply the fix in Debian, batch this with other bugfixes and get this unblocked for migration to Debian testing; I’ll try to do this at the BSP at the end of March
  3. once it’s in Debian testing, feature/buster will FTBFS and I’ll have to resolve the merge conflict

#16 Updated by CyrilBrulebois 2019-04-02 10:49:49

I think I now understand what the current (in feature/buster) patch does, but I’m not sure how to forward these changes with the new apparmor code (as of 2.13.2-10).

I’d be happy to get from you an updated hunk for the /etc/apparmor.d/abstractions/base file…

#17 Updated by intrigeri 2019-04-02 12:56:06

CyrilBrulebois wrote:
> I’d be happy to get from you an updated hunk for the /etc/apparmor.d/abstractions/base file…

I’ve done one of the possible conflict resolutions and will push once I confirm it at least fixes the FTBFS. Then our test suite should tell us if my conflict resolution breaks stuff.

#18 Updated by intrigeri 2019-04-02 13:40:14

  • Target version changed from Tails_3.14 to Tails_4.0

#19 Updated by intrigeri 2019-04-02 13:42:12

  • Assignee changed from intrigeri to CyrilBrulebois
  • QA Check set to Ready for QA

CyrilBrulebois, hefee I’ve pushed a candidate conflict resolution that allows the build to reach the next failure (Bug #16604).

#20 Updated by intrigeri 2019-04-03 13:28:39

  • Status changed from In Progress to Resolved
  • Assignee deleted (CyrilBrulebois)
  • % Done changed from 20 to 100
  • QA Check changed from Ready for QA to Pass

What this ticket was about has been fixed on feature/buster. Please file a new, dedicated ticket if I got the merge conflict resolution wrong :)