cmd,interfaces: add initial support for Solus #3720

ikeydoherty · 2017-08-11T17:37:05Z

Do not use re-exec on Solus
Allow autogen to pass $@ arguments to configure script
Recognise Solus as a "classic" distribution
Support usr-merge/bi-arch confinement library paths
Fix confinement support for "nvidia-arch" GL functionality
Support Solus's GL "linux-driver-management" layout
Fix bind-mount confinement issues for snapd directory

Signed-off-by: Ikey Doherty ikey@solus-project.com

zyga

My initial feeling is LGTM though please check the libraries and remove any unneeded cruft that is just there because we also support a weird hybrid ubuntu 14.04 with deputy systemd that you don't need.

Some of the apparmor rules may need tweaking later on, specifically we might make the opengl parts conditional on solus but I don't think we ought to block on that.

zyga · 2017-08-11T17:38:36Z

cmd/snap-confine/snap-confine.apparmor.in

+    /usr/lib64/libcap.so* mr,
+    /usr/lib64/libcgmanager.so* mr,
+    /usr/lib64/libdl-[0-9]*.so* mr,
+    /usr/lib64/libnih.so* mr,


libnih is I think only used on 14.04 systems, you may not need those unless they are really present on solus.

I'll drop nih

zyga · 2017-08-11T17:39:46Z

cmd/snap-confine/snap-confine.apparmor.in

+        /usr/lib64/libgcc_s.so* mr,
+
+        # normal libs in order biarch + usr-merged
+        /usr/lib64/libapparmor.so* mr,


Same comment as above (may need pruning)

Same comment from me on these. Instead of adding yours, can you instead change this:

/lib/@{multiarch}/ld-*.so mr, # libc, you are funny /lib/@{multiarch}/libc{,-[0-9]*}.so* mr, /lib/@{multiarch}/libpthread{,-[0-9]*}.so* mr, /lib/@{multiarch}/librt{,-[0-9]*}.so* mr, /lib/@{multiarch}/libgcc_s.so* mr, # normal libs in order /lib/@{multiarch}/libapparmor.so* mr, /lib/@{multiarch}/libcgmanager.so* mr, /lib/@{multiarch}/libnih.so* mr, /lib/@{multiarch}/libnih-dbus.so* mr, /lib/@{multiarch}/libdbus-1.so* mr, /lib/@{multiarch}/libudev.so* mr, /usr/lib/@{multiarch}/libseccomp.so* mr, /lib/@{multiarch}/libseccomp.so* mr,

to:

/{,usr/}lib{,32,64,x32}/{,@{multiarch}/}ld-*.so mrix, # libc, you are funny /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libc{,-[0-9]*}.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libpthread{,-[0-9]*}.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}librt{,-[0-9]*}.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libgcc_s.so* mr, # normal libs in order /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libapparmor.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libcgmanager.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libnih.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libnih-dbus.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libdbus-1.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libudev.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libseccomp.so* mr,

zyga · 2017-08-11T17:40:25Z

cmd/snap-confine/snap-confine.apparmor.in

    mount options=(rw rslave) -> /tmp/snap.rootfs_*/lib/modules/,

    mount options=(rw rbind) /var/log/ -> /tmp/snap.rootfs_*/var/log/,
    mount options=(rw rslave) -> /tmp/snap.rootfs_*/var/log/,

    mount options=(rw rbind) /usr/src/ -> /tmp/snap.rootfs_*/usr/src/,
    mount options=(rw rslave) -> /tmp/snap.rootfs_*/usr/src/,
+


I'm curious about those two rules, they look fine but I wasn't aware we need them or that we perform those operations.

zyga

Better but one more try maybe :)

zyga · 2017-08-11T17:51:57Z

cmd/snap-confine/snap-confine.apparmor.in

+    /usr/lib64/libdbus-1.so* mr,
+    /usr/lib64/libudev.so* mr,
+    /usr/lib64/libseccomp.so* mr,
+    /usr/lib64/libseccomp.so* mr,


zyga

Looks good, just one question.

zyga · 2017-08-11T17:55:37Z

cmd/autogen.sh

@@ -45,6 +45,9 @@ case "$ID" in
 		# patches find their way into the distribution.
 		extra_opts="--libexecdir=/usr/lib/snapd --disable-apparmor"
 		;;
+	solus)
+		extra_opts="--with-snap-mount-dir=/snap --enable-merged-usr --enable-nvidia-arch $@"


Curious about the $@ I didn't notice it on my first read.

In the Solus package we do:

%autogen which actually calls ./autogen.sh %CONFOPTS% which passes all the configure arguments along, this makes autogen.sh complete the chain and pass them along to configure so that the whole thing is configured properly in one go

Does anyone actually use this script in packaging? AFAIK, it was originally created for the test harness...

Yeah - it lets you configure the snap confine part, I'm using that within the package.yml ...

ikeydoherty · 2017-08-11T18:08:15Z

I'd agree that as the Solus support gets fleshed out that we might want that stuff to be conditional to save up spamming the rules/filters, and once we're at the multilib cross-roads we might want some Solus helper code to correctly append to the rules

niemeyer

Looks reasonable. One question, one problem we need to solve, and we need a review from jdstrand on those rule changes.

niemeyer · 2017-08-12T18:32:51Z

cmd/snap-confine/snap-confine.apparmor.in

+    /usr/lib64/libc{,-[0-9]*}.so* mr,
+    /usr/lib64/libpthread{,-[0-9]*}.so* mr,
+    /usr/lib64/librt{,-[0-9]*}.so* mr,
+    /usr/lib64/libgcc_s.so* mr,


Let's please get a pass by @jdstrand on these rules.

These rules are fine on their own, but I think we want to make this more futureproof since we're starting to bring on more and more apparmor-enabled distros that don't follow Debian/Ubuntu directories. I suggest instead of your changes, changing these:

/lib/@{multiarch}/ld-*.so mr, # libc, you are funny /lib/@{multiarch}/libc{,-[0-9]*}.so* mr, /lib/@{multiarch}/libpthread{,-[0-9]*}.so* mr, /lib/@{multiarch}/librt{,-[0-9]*}.so* mr, /lib/@{multiarch}/libgcc_s.so* mr, # normal libs in order /lib/@{multiarch}/libapparmor.so* mr, /lib/@{multiarch}/libcgmanager.so* mr, /lib/@{multiarch}/libdl-[0-9]*.so* mr, /lib/@{multiarch}/libnih.so* mr, /lib/@{multiarch}/libnih-dbus.so* mr, /lib/@{multiarch}/libdbus-1.so* mr, /lib/@{multiarch}/libudev.so* mr, /usr/lib/@{multiarch}/libseccomp.so* mr, /lib/@{multiarch}/libseccomp.so* mr,

to:

/{,usr/}lib{,32,64,x32}/{,@{multiarch}/}ld-*.so mrix, # libc, you are funny /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libc{,-[0-9]*}.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libpthread{,-[0-9]*}.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}librt{,-[0-9]*}.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libgcc_s.so* mr, # normal libs in order /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libapparmor.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libcgmanager.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libdl-[0-9]*.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libnih.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libnih-dbus.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libdbus-1.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libudev.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libseccomp.so* mr,

niemeyer · 2017-08-12T18:44:07Z

interfaces/builtin/opengl.go

+  /var/lib/snapd/hostfs/usr/lib*/glx-provider/** rm,
+  /var/lib/snapd/hostfs/usr/lib*/libcuda* rm,
+  /var/lib/snapd/hostfs/usr/lib*/libn* rm,
+  /var/lib/snapd/hostfs/usr/lib*/lib{GL,EGL}* rm,


Why is that necessary now and wasn't necessary before? @zyga, @mvo?

Note we have some logic under cmd/snap-confine/mount-support-nvidia.c related to this.

Well the comment in the context does explain that, its required for Solus NVIDIA libraries, which are accessed under /usr/lib{,64}/glx-provider due to the /usr/lib*/libGL type symlinks, and the rest of the libs (actual NVIDIA ones, not conflicting OpenGL ones) live in the main library directory. And the non-Solus part was never present because the rules were created for Arch Linux which doesn't actually have full apparmor confinement, so it was never exposed until now.

Exactly as @ikeydoherty explained. In solus nvidia layout is similar to arch so snap-confine was built with --with-nvidia-arch which was never confined to begin with.

@zyga Sorry for being a bit slow, here but the question is this: how are people able to use nvidia libraries on Ubuntu if we don't have those rules, and where is the rule in the nvidia support of snap-confine that puts those libraries into /var/lib/snapd/lib/gl as they should be?

There are two implementations of nvidia support, one for "ubuntu" like systems and one for "arch" like systems. The ubuntu part had the correct apparmor rules because we had to write those. The arch part never had because there was no good place to actually explore and test those. Solus is "arch" like and with enabled apparmor was the first distribution to explore this combination.

Note that on "arch" like systems /var/lib/snapd/lib/gl contains a tmpfs with a symlink farm so the effective files we access are different from what we did on Ubuntu.

niemeyer · 2017-08-12T18:47:57Z

mkversion.sh

@@ -32,6 +32,12 @@ if [ ! -z "$1" ]; then
    o=shell
 fi

+# If the version is passed in the environment during build, let's use that


That doesn't look right. It implies the logic that is telling the code what its version is will be outside the code itself, which means there's a very realistic probability of updating the code without changing the version. That will create a lot of very confusing issues, including serious breakages as we do take the version into account in some places.

The right way of doing this is running mkversion.sh when the code is extracted from git. The result will then have the version encoded statically and may be shipped anywhere without the git metadata.

Yes but this isn't being built from git, it's being built from the vendor tarball (which apparently doesn't know its own version) - thus passing the version in from the package metadata during build

@niemeyer this matches what we do elsewhere but since we don't want to force people to run dpkg-parsechangelogs we offer a simple "this is the version right here" already (via command line argument). This patch extends the feature to environment value since it is easier to integrate in souls.

I don't know if it's a good idea for mkversion to just be pulling random shell variables. I added the ability to pass it as a parameter so that you can control the input.

But mkversion is within the autogen pipeline, so to support correct and proper autogen invocation, the call to mkversion has to "learn" it from somewhere.. I also wouldn't really call it "random" given that its part of the documented ypkg build environment, which is sanely controlled. If it's gonna be that much of a problem I can split it to call mkversion prior to the autogen call, but I'd still need the parameters passed to configure like I'm doing now (Otherwise, it's a pretty pointless autogen)

I suggest calling it before the autogen call, as I do for the Fedora packaging.

I don't think we want environment variable, positional parameters, or flag parameters that provide a version into this script. We want this script to tell the version based on the git data, and we want this version to be statically saved into the filesystem so that it can be packed. If we have vendor tarballs that do not contain their own version today, these tarballs are broken and should be fixed. We want the source code to know its version, instead of expecting the person that builds the tarball to keep its version in mind and pass it in via a parameter. That latter approach will definitely result in binaries reporting their version incorrectly eventually.

Let's please fix any such broken tarballs now, while it's early and we haven't suffered any major pain due to that.

codecov-io · 2017-08-14T10:42:02Z

Codecov Report

Merging #3720 into master will decrease coverage by <.01%.
The diff coverage is 33.33%.

@@            Coverage Diff             @@
##           master    #3720      +/-   ##
==========================================
- Coverage    75.7%   75.69%   -0.01%     
==========================================
  Files         391      391              
  Lines       33936    33938       +2     
==========================================
- Hits        25690    25689       -1     
- Misses       6420     6423       +3     
  Partials     1826     1826

Impacted Files	Coverage Δ
interfaces/builtin/opengl.go	`100% <ø> (ø)`	⬆️
dirs/dirs.go	`95.06% <0%> (-2.41%)`	⬇️
cmd/cmd.go	`83.87% <100%> (ø)`	⬆️
cmd/snap/cmd_aliases.go	`93.33% <0%> (-1.67%)`	⬇️
interfaces/sorting.go	`98.71% <0%> (ø)`	⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bdd3e0a...b5c1804. Read the comment docs.

ikeydoherty · 2017-08-14T12:01:10Z

I've rebased the PR on master (dropping the commits/merges added on top of the commit) - and removed the mkversion changes, we'll invoke that in packaging prior to calling %autogen

- Do not use re-exec on Solus - Allow autogen to pass `$@` arguments to `configure` script - Recognise Solus as a "classic" distribution - Support usr-merge/bi-arch confinement library paths - Fix confinement support for "nvidia-arch" GL functionality - Support Solus's GL "linux-driver-management" layout - Fix bind-mount confinement issues for snapd directory Signed-off-by: Ikey Doherty <ikey@solus-project.com>

This hasn't _yet_ presented an issue in full confinement environments, as the only fully confined environment available is Ubuntu, and the snaps being tested are also built using the Ubuntu libraries. This change will now only make the NVIDIA libraries available if the nvidia kernel module is loaded and present, to ensure that confined snaps running on open source drivers will not run into any linking issues by exposing the host GL library into the runtime. Signed-off-by: Ikey Doherty <ikey@solus-project.com>

jdstrand

The security policy overall looks good, but I think we can future-proof a bit more (while still being cautious with our snap-confine's rules) and have a few small changes I'd like to see.

jdstrand · 2017-08-14T17:22:32Z

cmd/cmd.go

@@ -67,7 +67,7 @@ func distroSupportsReExec() bool {
 		return false
 	}
 	switch release.ReleaseInfo.ID {
-	case "fedora", "centos", "rhel", "opensuse", "suse", "poky", "arch":
+	case "fedora", "centos", "rhel", "opensuse", "suse", "poky", "arch", "solus":


Not (necessarily) to be fixed in this PR, but only seeing this code for the first time, I was surprised this list wasn't alphabetized.

I'll adjust this.

I don't know why we don't just have a list where re-exec is enabled rather than a disable list. The enable list is many times shorter (it's just Ubuntu and Debian).

Thought the same thing tbh

jdstrand · 2017-08-14T18:39:14Z

cmd/snap-confine/snap-confine.apparmor.in

+    /usr/lib64/libc{,-[0-9]*}.so* mr,
+    /usr/lib64/libpthread{,-[0-9]*}.so* mr,
+    /usr/lib64/librt{,-[0-9]*}.so* mr,
+    /usr/lib64/libgcc_s.so* mr,


These rules are fine on their own, but I think we want to make this more futureproof since we're starting to bring on more and more apparmor-enabled distros that don't follow Debian/Ubuntu directories. I suggest instead of your changes, changing these:

/lib/@{multiarch}/ld-*.so mr, # libc, you are funny /lib/@{multiarch}/libc{,-[0-9]*}.so* mr, /lib/@{multiarch}/libpthread{,-[0-9]*}.so* mr, /lib/@{multiarch}/librt{,-[0-9]*}.so* mr, /lib/@{multiarch}/libgcc_s.so* mr, # normal libs in order /lib/@{multiarch}/libapparmor.so* mr, /lib/@{multiarch}/libcgmanager.so* mr, /lib/@{multiarch}/libdl-[0-9]*.so* mr, /lib/@{multiarch}/libnih.so* mr, /lib/@{multiarch}/libnih-dbus.so* mr, /lib/@{multiarch}/libdbus-1.so* mr, /lib/@{multiarch}/libudev.so* mr, /usr/lib/@{multiarch}/libseccomp.so* mr, /lib/@{multiarch}/libseccomp.so* mr,

to:

/{,usr/}lib{,32,64,x32}/{,@{multiarch}/}ld-*.so mrix, # libc, you are funny /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libc{,-[0-9]*}.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libpthread{,-[0-9]*}.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}librt{,-[0-9]*}.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libgcc_s.so* mr, # normal libs in order /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libapparmor.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libcgmanager.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libdl-[0-9]*.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libnih.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libnih-dbus.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libdbus-1.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libudev.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libseccomp.so* mr,

jdstrand · 2017-08-14T18:39:27Z

cmd/snap-confine/snap-confine.apparmor.in

+    /usr/lib64/libdl-[0-9]*.so* mr,
+    /usr/lib64/libdbus-1.so* mr,
+    /usr/lib64/libudev.so* mr,
+    /usr/lib64/libseccomp.so* mr,


jdstrand · 2017-08-14T18:41:14Z

cmd/snap-confine/snap-confine.apparmor.in

@@ -154,13 +168,15 @@
    mount options=(rw rslave) -> /tmp/snap.rootfs_*/run/,

    mount options=(rw rbind) {/usr,}/lib/modules/ -> /tmp/snap.rootfs_*/lib/modules/,
+    mount options=(rw rbind) {/usr,}/lib64/modules/ -> /tmp/snap.rootfs_*/lib/modules/,


Instead of adding your rule, can you change this:

mount options=(rw rbind) {/usr,}/lib/modules/ -> /tmp/snap.rootfs_*/lib/modules/,

to:

mount options=(rw rbind) {/usr,}/lib{,32,64,x32}/modules/ -> /tmp/snap.rootfs_*/lib/modules/,

jdstrand · 2017-08-14T18:45:29Z

cmd/snap-confine/snap-confine.apparmor.in

+        /usr/lib64/libgcc_s.so* mr,
+
+        # normal libs in order biarch + usr-merged
+        /usr/lib64/libapparmor.so* mr,


Same comment from me on these. Instead of adding yours, can you instead change this:

/lib/@{multiarch}/ld-*.so mr, # libc, you are funny /lib/@{multiarch}/libc{,-[0-9]*}.so* mr, /lib/@{multiarch}/libpthread{,-[0-9]*}.so* mr, /lib/@{multiarch}/librt{,-[0-9]*}.so* mr, /lib/@{multiarch}/libgcc_s.so* mr, # normal libs in order /lib/@{multiarch}/libapparmor.so* mr, /lib/@{multiarch}/libcgmanager.so* mr, /lib/@{multiarch}/libnih.so* mr, /lib/@{multiarch}/libnih-dbus.so* mr, /lib/@{multiarch}/libdbus-1.so* mr, /lib/@{multiarch}/libudev.so* mr, /usr/lib/@{multiarch}/libseccomp.so* mr, /lib/@{multiarch}/libseccomp.so* mr,

to:

/{,usr/}lib{,32,64,x32}/{,@{multiarch}/}ld-*.so mrix, # libc, you are funny /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libc{,-[0-9]*}.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libpthread{,-[0-9]*}.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}librt{,-[0-9]*}.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libgcc_s.so* mr, # normal libs in order /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libapparmor.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libcgmanager.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libnih.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libnih-dbus.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libdbus-1.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libudev.so* mr, /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libseccomp.so* mr,

jdstrand · 2017-08-14T18:54:57Z

cmd/snap-confine/snap-confine.apparmor.in

@@ -235,6 +251,9 @@
    /sys/module/nvidia/version r,
    /usr/** r,
    mount options=(rw bind) /usr/lib/nvidia-*/ -> /{tmp/snap.rootfs_*/,}var/lib/snapd/lib/gl/,
+    /tmp/snap.rootfs_*/var/lib/snapd/lib/gl/* w,
+    mount fstype=tmpfs none -> /tmp/snap.rootfs_*/var/lib/snapd/lib/gl/,


I think you should be able to change this rule to be:

mount fstype=tmpfs options=(rw nodev nosuid) none -> /tmp/snap.rootfs_*/var/lib/snapd/lib/gl/,

Can you do so and verify it still works?

That's what I originally had, which is why I stripped options from it (didn't work, I'd copy-edited the other tmpfs one i'd found)

Can you paste the denial when it didn't work?

jdstrand · 2017-08-14T19:08:42Z

cmd/snap-confine/snap-confine.apparmor.in

@@ -235,6 +251,9 @@
    /sys/module/nvidia/version r,
    /usr/** r,
    mount options=(rw bind) /usr/lib/nvidia-*/ -> /{tmp/snap.rootfs_*/,}var/lib/snapd/lib/gl/,
+    /tmp/snap.rootfs_*/var/lib/snapd/lib/gl/* w,
+    mount fstype=tmpfs none -> /tmp/snap.rootfs_*/var/lib/snapd/lib/gl/,
+    mount options=(remount,ro) -> /tmp/snap.rootfs_*/var/lib/snapd/lib/gl/,


For consistency with other mount rules in the policy, can you change this rule of yours to be this equivalent rule (options may be space or comma separated):

mount options=(remount ro) -> /tmp/snap.rootfs_*/var/lib/snapd/lib/gl/,

jdstrand · 2017-08-14T19:09:24Z

cmd/snap-confine/snap-confine.apparmor.in

+        /usr/lib64/libdbus-1.so* mr,
+        /usr/lib64/libudev.so* mr,
+        /usr/lib64/libseccomp.so* mr,
+


jdstrand · 2017-08-14T19:16:41Z

interfaces/builtin/opengl.go

+  /var/lib/snapd/hostfs/usr/lib*/glx-provider/** rm,
+  /var/lib/snapd/hostfs/usr/lib*/libcuda* rm,
+  /var/lib/snapd/hostfs/usr/lib*/libn* rm,
+  /var/lib/snapd/hostfs/usr/lib*/lib{GL,EGL}* rm,


I think we want something more like this:

# Solus LDM locations /var/lib/snapd/hostfs/usr/lib{,32,64}/glx-provider/**.so{,.*} rm, /var/lib/snapd/hostfs/usr/lib{,32,64}/libcuda*.so{,.*} rm, /var/lib/snapd/hostfs/usr/lib{,32,64}/libnvidia*.so{,.*} rm, /var/lib/snapd/hostfs/usr/lib{,32,64}/lib{GL,EGL}.so{,.*} rm,

Can you test and report back any errors? I thought using lib{,32,64} is good for future-proofing, but I also wanted to tighten up the rules to only mmap() .so files. Also, libn* seemed too generic so I guessed you wanted libnvidia*, but please adjust as necessary. If the above doesn't work for you, feel free to adjust and/or paste the apparmor denials.

Well libnv maybe, there are a few in there but yeah we'll tighten them up and allow the biarch approach (We do have the lib32 dirs too fwiw)

jdstrand · 2017-08-29T16:39:37Z

Note if you merge with upstream/master, you'll get #3789 which will address my comments regarding future-proofing the policy. Other comments remain.

zyga · 2017-08-30T17:24:20Z

I'll try to pick this up and get it merged.

niemeyer · 2017-09-01T18:49:03Z

I've heard from @zyga today in the standup that this is being broken down into smaller pieces, so I'm closing this one.

@zyga, please keep us posted about the progress on this.

zyga approved these changes Aug 11, 2017

View reviewed changes

ikeydoherty force-pushed the solus-support branch from 893ba8b to f7559c9 Compare August 11, 2017 17:50

zyga reviewed Aug 11, 2017

View reviewed changes

zyga changed the title ~~Add initial support for Solus~~ cmd,interfaces: add initial support for Solus Aug 11, 2017

ikeydoherty force-pushed the solus-support branch from f7559c9 to e95377e Compare August 11, 2017 17:53

zyga approved these changes Aug 11, 2017

View reviewed changes

ikeydoherty force-pushed the solus-support branch from e95377e to 65279c9 Compare August 11, 2017 18:29

niemeyer requested changes Aug 12, 2017

View reviewed changes

ikeydoherty force-pushed the solus-support branch from 2c25422 to 522d897 Compare August 14, 2017 12:00

ikeydoherty force-pushed the solus-support branch from 522d897 to b5c1804 Compare August 14, 2017 12:02

zyga requested a review from jdstrand August 14, 2017 12:06

jdstrand suggested changes Aug 14, 2017

View reviewed changes

Merge branch 'master' into solus-support

8127b70

niemeyer closed this Sep 1, 2017

cmd,interfaces: add initial support for Solus #3720

cmd,interfaces: add initial support for Solus #3720

Conversation

ikeydoherty commented Aug 11, 2017 • edited

zyga left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zyga left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zyga left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ikeydoherty commented Aug 11, 2017

niemeyer left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zyga Aug 13, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

niemeyer Aug 14, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov-io commented Aug 14, 2017 • edited

Codecov Report

ikeydoherty commented Aug 14, 2017

jdstrand left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jdstrand commented Aug 29, 2017

zyga commented Aug 30, 2017

niemeyer commented Sep 1, 2017

ikeydoherty commented Aug 11, 2017 •

edited

zyga Aug 13, 2017 •

edited

niemeyer Aug 14, 2017 •

edited

codecov-io commented Aug 14, 2017 •

edited