We are developing webots (https://github.com/omichel/webots) and would like to provide a snap for it on Linux. I have created a snap with classic confinement which works fine locally and which I just pushed to snapcraft.io.
I tried hard to make it work with strict confinement, but failed mainly for the following reason: webots uses pcilib to read information on the graphics card (model, memory, etc. and deduce the OpenGL capabilities). Unfortunately, AppArmor doesn’t like it and prevents webots from reading this file in particular:
pcilib: Cannot open /sys/bus/pci/devices/0000:00:17.0/resource: Permission denied
I tried to add a plug in my snapcraft.yaml file, but that doesn’t help:
Shall I give up with strict confinement and ask a review for a classic confinement? Or is there still any hope that webots could be allowed to read /sys/bus/pci?
well, is that filesystem node readable by the user executing the app ? interfaces only make the devices visible to your app, they do not mangle filesystem permissions of what you want to access.
# files in /proc/bus/pci (eg, 'lspci -A linux-proc')
@{PROC}/bus/pci/{,**} r,
which should give you full read access to all the subdirs as i understand it … did you actually connect the plug after installing the snap using snap connect ... (it does not auto-connect) …
also … do you see any “DENIED” messages in syslog or journalctl ?
Yes, if I type: snap connect webots:hardware-observe, then it works! Thank you.
Sorry I am new to snap… I am not sure what this implies. Shall the user type this before they can start Webots? In such a case, it may be better to add this snap connect in the launcher of Webots, so that it is transparent to the user?
if this functionallity is really needed for your app you can turn this request for classic confinement into one for auto-connecting the hardware-observe interface … you can not do the connection from somewhere inside your snap (the purpose is to give the user control over what apps can do and what they can not, allowing the app developer to just connect would defeat that purpose)
it is either the manual snap connect ..., a graphical switch in the GUI software application (Ubuntu/GNOME software) or an approved auto connection that is managed by the store during installation of your snap.
Unfortunately, this functionality is really needed indeed as it helps to determine which OpenGL capabilities are available, including the amount of GPU RAM, before using them (choice of textures resolution, etc.).
However, I have now another problem to address (related to shared memory allocation and mapping) which I will try to solve using another plug.
So, I believe I need to prepare a snap with a strict confinement that fully works before I ask for auto-connecting the necessary plugs and provide an explanation for each of them.
So, if you agree, I will strike back on this post once everything is ready for review.
Now that the hardware-observe problem is fixed, webots starts and displays the 3D view, the robot are running apparently properly. However, I get many warnings which look serious:
[0829/134159.941525:WARNING:stack_trace_posix.cc(704)] Failed to open file: /snap/core18/1074/lib/x86_64-linux-gnu/ld-2.27.so
Error: Permission denied
[0829/134159.969768:WARNING:stack_trace_posix.cc(704)] Failed to open file: /snap/core18/1074/lib/x86_64-linux-gnu/ld-2.27.so
Error: Permission denied
[40158:40178:0829/134159.995450:ERROR:zygote_host_impl_linux.cc(271)] Failed to adjust OOM score of renderer with pid 40188: Permission denied (13)
[40188:40188:0829/134207.381195:ERROR:broker_posix.cc(46)] Received unexpected number of handles
[40188:40188:0829/134207.381612:ERROR:command_buffer_proxy_impl.cc(101)] ContextResult::kFatalFailure: AllocateAndMapSharedMemory failed
[40188:40188:0829/134207.417918:ERROR:broker_posix.cc(46)] Received unexpected number of handles
Unfortunately I have no clue to address them. I googled a bit with these errors, but got no luck…
I managed to get rid of most of the warnings and errors reported by snappy-debug. Remain only 4 warnings which I assume are harmless because the application behaves properly.
The only requirement I have for you is to enable auto-connection of the hardware-observe interface: snap connect webots:hardware-observe. This is really needed by the application to determine the model of the graphics card and adapt the OpenGL settings automatically from this information. Could that be an acceptable requirement?
I just pushed a new build of my app (webots) using snapcraft push for your review.
Here are the hopefully harmless warnings I get from snappy-debug:
kernel.printk_ratelimit = 0
= AppArmor =
Time: Sep 10 07:02:16
Log: apparmor="DENIED" operation="open" profile="snap.webots.webots" name="/proc/31489/mem" pid=31489 comm="webots-bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
File: /proc/31489/mem (read)
Suggestion:
* adjust program to not access '@{PROC}/@{pid}/mem'
= AppArmor =
Time: Sep 10 07:02:16
Log: apparmor="DENIED" operation="open" profile="snap.webots.webots" name="/proc/31496/setgroups" pid=31496 comm="webots-bin" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000
File: /proc/31496/setgroups (write)
Suggestion:
* adjust program to not access '@{PROC}/@{pid}/setgroups'
= AppArmor =
Time: Sep 10 07:02:17
Log: apparmor="DENIED" operation="open" profile="snap.webots.webots" name="/proc/31497/mem" pid=31497 comm="QtWebEngineProc" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
File: /proc/31497/mem (read)
Suggestion:
* adjust program to not access '@{PROC}/@{pid}/mem'
= AppArmor =
Time: Sep 10 07:02:20
Log: apparmor="DENIED" operation="open" profile="snap.webots.webots" name="/etc/openal/alsoft.conf" pid=31489 comm="webots-bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
File: /etc/openal/alsoft.conf (read)
Suggestions:
* adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON
* adjust snap to use snap layouts (https://forum.snapcraft.io/t/snap-layouts/7207)
* add 'system-files (see https://forum.snapcraft.io/t/the-system-files-interface for acceptance criteria)' to 'plugs'
Sure. I’ve converted this topic into a request for hardware-observe auto-connect.
+1 to auto-connect hardware-observe. @reviewers - can others vote?
Revision 4 passed automated review.
‘man proc’ has this to say about this file:
/proc/[pid]/mem
This file can be used to access the pages of a process's memory
through open(2), read(2), and lseek(2).
Permission to access this file is governed by a ptrace access mode
PTRACE_MODE_ATTACH_FSCREDS check; see ptrace(2).
We’ve not allowed this access thus far since we can’t currently limit the access to the pids of the snap and the access could allow access to sensitive information between snaps and the system. You’d have to see why your snap is accessing this to be sure it is ok (it may try, discover it can’t and fallback to other behavior).
It sounds like the snap may be trying to setup a user namespace, since it is common for an application to write to this file to disable this syscall. If your application is otherwise behaving normally, this is safe to ignore since the snap sandbox will disable unsafe use of this syscall.
As mentioned in snappy-debug, you can get rid of this either by using a layout or use of system-files. In this case, perhaps have the layout point to $SNAP/etc/openal.
Thank you for the detailed answer. It helps a lot. I believe there are fallbacks for all these attempts to read forbidden files. So, it shouldn’t affect the behavior of my app.
I just uploaded a new release (5) which fixes a couple of little glitches of the previous one (4), including the execution and compilation of C/C++/Python and Java robot controllers. I still need the auto-connection of hardware-observe for this release. So, please @reviewers, check this latest version.
The first vote (+1) was cast by @jdstrand 8 days ago and no other vote came meanwhile. Shall we enter the 3 day extension period now? I am looking forward to see my app available on the snap store with the auto-connection working.
+1 from me; auto-connect of hardware-observe makes sense and I don’t see another way of allowing the application to check for the existing graphics card. It also seems well-targetted and rather innocuous, so there.
