Tmux/screen on Ubuntu Core

chrmod · May 7, 2017, 9:52am

Running terminal multiplexer on Ubuntu Core does not seem to be a very straightforward task.

Snap sandboxing not only change working directory (which can be fixed with home plug), but also makes running another snaps break with this error:

support process for mount namespace capture exited abnormally

Is there a way to get run other snaps from within one?

chrmod · May 7, 2017, 9:57am

Maybe I will describe what I’m trying to achieve here.
I’m running Ubuntu Core on Raspberrypi and what to setup an persistent irc client, to which I can always remotely log in.
The parts of that setup are:

mosh - to maintain network connection to Raspberrypi
tmux - to host always running session
weechat - for irc

Was able to cross compile and package all those applications on travis, all of them run. But I cannot find a way to run one from withing the other. That is connect to mosh-server, attach tmux session to run weechat.

Is Ubuntu Core even a proper host for such setup?

ogra · May 7, 2017, 11:26am

sounds like you are trying to keep each of these apps in a separate snap package instead of bundling them into one.

doing it that way will require that the snaps use the right interfaces to communicate or get device access. if you actually want to keep them separate you will need to identify where the communication paths go along and how to interconnect them via interfaces (either through existing ones or if there is no interface for the task yet, request one).

if the setup is single-purpose for acting as irc proxy anyway i’d simply put all three together into one snap and adjust paths and configs to operate inside that environment.

UbuntuCore should definitely be a proper host for it, the setup you pick makes it a more or a less complex task though.

https://github.com/ogra1/upnp-server might give you some ideas how to bundle different services.

chrmod · May 7, 2017, 11:46am

Thank you for the answer and tips.

I will definitely give this approach a shot, though I thought that keeping those as separate snaps make them more universal. Being a heavy tmux user I can think of many use cases of running one on device as raspberrypi.

I’m not exactly getting the interface communication part you’ve mentioned. There are no resources I can think of, that those applications should be sharing.

Getting back to original question. Is there a way to run snap from inside another snap?

zyga-snapd · May 8, 2017, 7:19am

Normal snaps are not allowed to run other snaps. We can allow that via an interface (none exists now) but this would have to be designed.

As a small request, can you please run tmux and then run another command you want to run, that fails with the error message given above, after setting SNAP_CONFINE_DEBUG=yes. This will allow me to make sure nothing else is missing.

chrmod · May 8, 2017, 8:47am

SNAP_CONFINE_DEBUG=yes /snap/bin/weechat-armhf.weechat

output:

DEBUG: setting argv[0] to snap-confine
DEBUG: security tag is snap.weechat-armhf.weechat
DEBUG: binary to run is /usr/lib/snapd/snap-exec
DEBUG: apparmor label on snap-confine is: snap.tmux-armhf.tmux//null-/usr/bin/snap//null-/usr/lib/snapd/snap-confine
DEBUG: apparmor mode is: complain
DEBUG: preparing seccomp profile associated with security tag snap.weechat-armhf.weechat
DEBUG: host arch (kernel) is '1073741864'
DEBUG: native arch (userspace) is '1073741864'
DEBUG: creating namespace group directory /run/snapd/ns
DEBUG: opening namespace group directory /run/snapd/ns
DEBUG: opening lock file for group directory
DEBUG: locking the namespace group directory
DEBUG: sanity timeout initialized and set for three seconds
DEBUG: sanity timeout reset and disabled
DEBUG: namespace group directory does not require intialization
DEBUG: unlocking the namespace group directory
DEBUG: opening namespace group directory /run/snapd/ns
DEBUG: opening lock file for namespace group weechat-armhf
DEBUG: acquiring exclusive lock for namespace group weechat-armhf
DEBUG: sanity timeout initialized and set for three seconds
DEBUG: sanity timeout reset and disabled
DEBUG: acquired exclusive lock for namespace group weechat-armhf
DEBUG: initializing new namespace group weechat-armhf
DEBUG: forking support process for mount namespace capture
DEBUG: forked support process has pid 8298
DEBUG: unsharing the mount namespace
DEBUG: forked support process has pid 0
DEBUG: changing apparmor hat of the support process for mount namespace capture
DEBUG: changing apparmor hat to mount-namespace-capture-helper
DEBUG: ensuring that parent process is still alive
DEBUG: waiting for a eventfd data from the parent process to continue
DEBUG: sanity timeout initialized and set for three seconds
DEBUG: scratch directory for constructing namespace: /tmp/snap.rootfs_SDp5EK
DEBUG: performing operation: (disabled) use debug build to see details
DEBUG: performing operation: (disabled) use debug build to see details
DEBUG: performing operation: (disabled) use debug build to see details
DEBUG: performing operation: (disabled) use debug build to see details
DEBUG: performing operation: (disabled) use debug build to see details
DEBUG: performing operation: (disabled) use debug build to see details
DEBUG: performing operation: (disabled) use debug build to see details
DEBUG: performing operation: (disabled) use debug build to see details
DEBUG: performing operation: (disabled) use debug build to see details
DEBUG: performing operation: (disabled) use debug build to see details
DEBUG: performing operation: (disabled) use debug build to see details
DEBUG: performing operation: (disabled) use debug build to see details
DEBUG: performing operation: (disabled) use debug build to see details
DEBUG: performing operation: pivot_root /tmp/snap.rootfs_SDp5EK /tmp/snap.rootfs_SDp5EK//var/lib/snapd/hostfs
DEBUG: performing operation: (disabled) use debug build to see details
DEBUG: performing operation: rmdir /var/lib/snapd/hostfs//tmp/snap.rootfs_SDp5EK
DEBUG: performing operation: (disabled) use debug build to see details
DEBUG: performing operation: (disabled) use debug build to see details                                                                                                                                                                 
DEBUG: performing operation: (disabled) use debug build to see details                                                                                                                                                                 
DEBUG: performing operation: (disabled) use debug build to see details                                                                                                                                                                 
DEBUG: performing operation: (disabled) use debug build to see details                                                                                                                                                                 
DEBUG: performing operation: (disabled) use debug build to see details                                                                                                                                                                 
DEBUG: performing operation: (disabled) use debug build to see details                                                                                                                                                                 
DEBUG: performing operation: (disabled) use debug build to see details                                                                                                                                                                 
DEBUG: sc_setup_mount_profiles: weechat-armhf                                                                                                                                                                                          
DEBUG: opening mount profile /var/lib/snapd/mount/snap.weechat-armhf.fstab                                                                                                                                                             
DEBUG: mount profile /var/lib/snapd/mount/snap.weechat-armhf.fstab doesn't exist, ignoring                                                                                                                                             
DEBUG: asking support process for mount namespace capture (pid: 8298) to perform the capture                                                                                                                                           
DEBUG: waiting for the support process for mount namespace capture to exit                                                                                                                                                             
DEBUG: sanity timeout reset and disabled                                                                                                                                                                                               
DEBUG: capturing mount namespace of process 8293 in namespace group weechat-armhf                                                                                                                                                      
support process for mount namespace capture exited abnormally

I’m guessing it fails on filesystem access, but those logs does not tell me much.

Any suggestion on how to progress?

BTW. @ogra, the approach with multiple apps in single snap seems to be working.

zyga-snapd · May 8, 2017, 8:49am

Can you look at dmesg | grep DENIED and share that too?

chrmod · May 8, 2017, 9:51am

there is nothing with DENIED, so I’m posting result of dmesg | grep denied:

[558140.782618] audit: type=1400 audit(1494236782.305:4681): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux" name="/etc/profile.d/" pid=8442 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0       
[558076.431624] audit: type=1400 audit(1494236717.953:4573): apparmor="ALLOWED" operation="exec" profile="snap.tmux-armhf.tmux" name="/bin/dmesg" pid=8388 comm="bash" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 target="snap.tmux-armhf.tmux//null-/bin/dmesg"
[558076.505263] audit: type=1400 audit(1494236718.037:4574): apparmor="ALLOWED" operation="file_inherit" profile="snap.tmux-armhf.tmux//null-/bin/dmesg" name="/dev/pts/0" pid=8388 comm="dmesg" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000
[558076.547148] audit: type=1400 audit(1494236718.077:4575): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux//null-/bin/dmesg" name="/snap/tmux-armhf/x1/lib/arm-linux-gnueabihf/libtinfo.so.5.9" pid=8388 comm="dmesg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[558076.590373] audit: type=1400 audit(1494236718.121:4576): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux//null-/bin/dmesg" name="/snap/tmux-armhf/x1/lib/arm-linux-gnueabihf/librt-2.24.so" pid=8388 comm="dmesg"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[558076.656758] audit: type=1400 audit(1494236718.189:4577): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux//null-/bin/dmesg" name="/snap/tmux-armhf/x1/lib/arm-linux-gnueabihf/libc-2.24.so" pid=8388 comm="dmesg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[558076.698556] audit: type=1400 audit(1494236718.229:4578): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux//null-/bin/dmesg" name="/snap/tmux-armhf/x1/lib/arm-linux-gnueabihf/libpthread-2.24.so" pid=8388 comm="dmesg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[558076.740865] audit: type=1400 audit(1494236718.273:4579): apparmor="ALLOWED" operation="file_mprotect" profile="snap.tmux-armhf.tmux//null-/bin/dmesg" name="/bin/dmesg" pid=8388 comm="dmesg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[558076.774254] audit: type=1400 audit(1494236718.305:4580): apparmor="ALLOWED" operation="file_mprotect" profile="snap.tmux-armhf.tmux//null-/bin/dmesg" name="/lib/arm-linux-gnueabihf/ld-2.23.so" pid=8388 comm="dmesg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[558076.814160] audit: type=1400 audit(1494236718.345:4581): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux//null-/bin/dmesg" name="/dev/kmsg" pid=8388 comm="dmesg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[558118.342179] audit: type=1400 audit(1494236759.873:4582): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux" name="/etc/profile.d/" pid=8417 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[558118.373570] audit: type=1400 audit(1494236759.905:4583): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux" name="/etc/profile.d/Z99-cloud-locale-test.sh" pid=8417 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[558118.410221] audit: type=1400 audit(1494236759.941:4584): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux" name="/etc/profile.d/Z99-cloudinit-warnings.sh" pid=8417 comm="bash" requested_mask="r" denied_mask="r"
fsuid=1000 ouid=0
[558118.449026] audit: type=1400 audit(1494236759.981:4585): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux" name="/etc/profile.d/bash_completion.sh" pid=8417 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[558118.483146] audit: type=1400 audit(1494236760.013:4586): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux" name="/usr/share/bash-completion/bash_completion" pid=8417 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[558118.572970] audit: type=1400 audit(1494236760.105:4587): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux" name="/etc/init.d/" pid=8417 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[558118.703014] audit: type=1400 audit(1494236760.233:4588): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux" name="/etc/bash_completion.d/" pid=8421 comm="ls" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[558118.737825] audit: type=1400 audit(1494236760.269:4589): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux" name="/etc/bash_completion.d/insserv" pid=8417 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[558120.259990] audit: type=1400 audit(1494236761.793:4590): apparmor="ALLOWED" operation="exec" profile="snap.tmux-armhf.tmux" name="/usr/bin/snap" pid=8422 comm="bash" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 target="snap.tmux-armhf.tmux//null-/usr/bin/snap"
[558120.300433] audit: type=1400 audit(1494236761.833:4591): apparmor="ALLOWED" operation="file_inherit" profile="snap.tmux-armhf.tmux//null-/usr/bin/snap" name="/dev/pts/0" pid=8422 comm="weechat-armhf.w" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000
[558140.782618] audit: type=1400 audit(1494236782.305:4681): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux" name="/etc/profile.d/" pid=8442 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[558140.817180] audit: type=1400 audit(1494236782.349:4682): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux" name="/etc/profile.d/Z99-cloud-locale-test.sh" pid=8442 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[558140.857338] audit: type=1400 audit(1494236782.389:4683): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux" name="/etc/profile.d/Z99-cloudinit-warnings.sh" pid=8442 comm="bash" requested_mask="r" denied_mask="r"
fsuid=1000 ouid=0
[558140.898701] audit: type=1400 audit(1494236782.429:4684): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux" name="/etc/profile.d/bash_completion.sh" pid=8442 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[558140.934203] audit: type=1400 audit(1494236782.465:4685): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux" name="/usr/share/bash-completion/bash_completion" pid=8442 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[558141.025243] audit: type=1400 audit(1494236782.557:4686): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux" name="/etc/init.d/" pid=8442 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[558141.155803] audit: type=1400 audit(1494236782.690:4687): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux" name="/etc/bash_completion.d/" pid=8446 comm="ls" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[558141.190429] audit: type=1400 audit(1494236782.722:4688): apparmor="ALLOWED" operation="open" profile="snap.tmux-armhf.tmux" name="/etc/bash_completion.d/insserv" pid=8442 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[558143.316989] audit: type=1400 audit(1494236784.850:4689): apparmor="ALLOWED" operation="exec" profile="snap.tmux-armhf.tmux" name="/usr/bin/snap" pid=8447 comm="bash" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 target="snap.tmux-armhf.tmux//null-/usr/bin/snap"
[558143.357225] audit: type=1400 audit(1494236784.890:4690): apparmor="ALLOWED" operation="file_inherit" profile="snap.tmux-armhf.tmux//null-/usr/bin/snap" name="/dev/pts/0" pid=8447 comm="weechat-armhf.w" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000

zyga-snapd · May 8, 2017, 9:54am

Aha, it seems this snap is in devmode.[quote=“chrmod, post:8, topic:499”]
[558143.316989] audit: type=1400 audit(1494236784.850:4689): apparmor=“ALLOWED” operation=“exec” profile=“snap.tmux-armhf.tmux” name="/usr/bin/snap" pid=8447 comm=“bash” requested_mask=“x” denied_mask=“x” fsuid=1000 ouid=0 target=“snap.tmux-armhf.tmux//null-/usr/bin/snap”
[558143.357225] audit: type=1400 audit(1494236784.890:4690): apparmor=“ALLOWED” operation=“file_inherit” profile=“snap.tmux-armhf.tmux//null-/usr/bin/snap” name="/dev/pts/0" pid=8447 comm=“weechat-armhf.w” requested_mask=“wr” denied_mask=“wr” fsuid=1000 ouid=1000
[/quote]

So this confirms my earlier suspicion. One snap tries to execute another snap. This is perfectly possible technically but it is currently disallowed outside of devmode and we’d need an interface to allow this.

chrmod · May 8, 2017, 10:11am

Alright. Thank you for the investigation.

If there is anything I can help you guys around introducing this new interface please let me know. I’ve already invested quite some time to snap and ubuntu core, so I guess learning how to write an interface would not harm me too much

zyga-snapd · May 8, 2017, 10:22am

This interface is a bit special as it would involve a new security backend. I imagine it would be a file that snapd would write and snap-confine would consult that contains a list of snaps that a given application can execute. It might also contain some special marker that is an invalid snap identifier to indicate that all snap applications may be executed (which would be useful for generic software like shells and other “application launchers”).

As a quick idea, snapd could create

/var/lib/snapd/snap2snap/snap.$SNAP_NAME.$APP_NAME

For tmux I think it should just be able to run any snap application because it is a shell wrapper. In that case the aforementioned file could just read @all

Following that, snap-confine would check if it is invoked from a snap and if so would match the invoked application with entries in that file. A match would mean it would carry on as usual. Lack of a match would result in an appropriate error message.

On snapd side, the new backend would be fairly trivial, it could be modelled after any of the other backends with the extra simplification that no executables are involved (similar to seccomp actually). A new set of methods would be defined, named after the backend name, that any interface could then start using.

After that we just need to decide how plugs, slots and connections determine the contents of that new file. There are plenty of possibilities that I can think of. We could add a plug/slot to each snap implicitly. Any snap could offer itsef as being runnable (the apps holidng the slot would then be runnable) from another snap. All apps would get the implicit slot as well. Connections between such snaps would them mean that apps associated with connected plugs are allowed to start the apps associated with connected slots.

We could also do it entirely without connections. Say just by defining a slot with some attributes and making that interface restricted so that it needs to be approved by the store.

jdstrand · May 8, 2017, 2:21pm

tldr;

This isn’t the way to do this IMO. Instead, figure out how to make something akin to ‘confinement: classic’ work for shells on Ubuntu Core.

details

Classic mode was specifically designed to address things like shells and multiplexers for ‘general snaps’ (eg, tmux by itself as opposed to tmux shipped in the snap). In fact, there is a tmux snap in the store right now that uses classic confinement (I realize it isn’t available on Core). Also, the premise of having ‘generalized snaps that interact in arbitrary ways’ goes against snappy’s design-- snaps are very intentionally meant to bundle and to only go outside their application area in very controlled ways.

Letting snaps execute other snaps binaries is a difficult proposition to have the expected usability experience (eg, how do you share files? what about IPC? seccomp? cgroups?) and it needs to be very carefully designed because interfaces are a contract between providers (slots) and consumers (plugs). If we allow something to ‘plugs’ binaries in /snap/bin from another snap, what is that saying? To me with the way we’ve currently defined interfaces is that it means that the plugging side can count on the providing side not changing in terms of invocation or output. I’m not sure that is tractable in the most general sense. This interface could be a special case and the contract redefined, but to what (ie, this needs design)? How will we make sure that this doesn’t degrade the experience? (eg, today, snaps are free to change how their /snap/bin binaries work because nothing (by design) depends on them)

Furthermore, I think we are probably going the wrong direction if we let users dictate in arbitrary, uncontrolled ways ‘this snap is allowed to execute this (sub)set of binaries from this other snap’. Presenting options for interface connections (‘this snap wants to use the network-manager interface’) is one thing (and already a difficult proposition for the user to understand the security implications or the trust being given to the snap), it is quite another to have them enter commands for letting snap ‘foo’ run ‘/snap/bin/bar.baz’, or similar.

If we achieved a proper design, there are several concerns with your idea such as:

‘snap-confine would check if it is invoked from a snap’ - how would it do that securely? A secure design would have to leverage LSM labeling, but that wouldn’t be cross-platform atm
IMO this crosses a line on exec() mediation I don’t think we want to cross. Up until now, snap-confine consumes files to setup a sandbox, but your idea puts snap-confine right at the heart of exec() mediation (ie, ‘should I allow exec of this or that?’). If the the LSM is already involved for the security label, the snap-confine logic could be greatly simplified to make an LSM query on if the access should be allowed or not (granted, this is still snap-confine performing mediation, but in a more robust manner). For example, if this were going to be implemented when AppArmor is the LSM, the allowed /snap/bin accesses each get a ‘Px rule’ in the security policy of the caller, snap-confine uses the libapparmor API to ask if /snap/bin is allowed, if not, EPERM, then exec
how do snaps transition from one snap’s mount namespace to another? Ie, if foo exec()s bar.baz, bar.baz must execute within the mount namespace of ‘bar’, not ‘foo’ for security and because ‘bar’ has no knowledge of ‘foo’ (how to work with it, etc, etc). However, this presents a usability issue because ‘foo’ may want to give ‘bar’ a file it owns. How would it do that? To put in more concrete terms, say the tmux snap has the ‘home’ interface and is allowed to execute ‘bar’, but ‘bar’ does not have the ‘home’ interface. tmux tries to give ‘bar’ a file, but it cannot. /tmp is in a different namespace, ‘bar’ confinement doesn’t allow sharing, etc. I very strongly feel it would be a mistake to expand 'bar’s confinement to include whatever 'tmux’s might allow
we’d have to consider the usability and security issues surrounding exec transitions for each LSM mediation type (ie, file, capability, dbus, network, mount, ptrace, signal and unix)
this design just will not work with seccomp because with seccomp you can only go more restrictive. As such, the tmux snap would really need to have unrestricted seccomp to be able to execute arbitrary /snap/bin commands, because the commands in /snap/bin might plugs anything (eg, running docker under tmux)
this design also won’t work with device cgroups. If tmux plugs something (eg, a serial-port, something quite reasonable for tmux to do), then tries to run something in /snap/bin that plugs something else, then the /snap/bin/binary will fail because the device isn’t in the cgroup for tmux
there are probably other things I’m missing since this is all OTOH

You could try to fix the seccomp and cgroup issues by trying:

if the command is in /snap/bin, snap run asks snapd to execute it on its behalf
snapd takes the security label of snap run and performs an LSM query to see if it is allowed, and if so, executes it

The security implications for getting snapd involved in this way are pretty scary cause it means this API for snapd has to be bullet-proof to not allow privilege escalation or confinement escape. Furthermore, it completely breaks the parent/child relationship of the caller/callee, breaks process groups, breaks process sessions, etc. It doesn’t solve the issues surrounding sharing files and would just be a very poor experience.

But classic confinement doesn’t suffer from any of these issues (sharing files isn’t totally transparent but at least possible). The big problem with classic confinement is that it doesn’t exist on Ubuntu Core. IMHO, the best solution would be figuring out how to address that. Perhaps that is simply a ‘confinement: shell’ that operates very much like ‘classic’ in terms of sandbox setup except that it is allowed on core, and we restrict its use. This allows tmux, screen, byobu, zsh, csh, etc, etc to work.

niemeyer · May 8, 2017, 8:47pm

Yes, the short version is that allowing snap to cross-execute without a more clear feature-oriented interface introduces one-on-one requirements, which means bringing into the snap world the benefits and pain of cross-package requisite handling. This is a major change and can’t be done lightly without proper and very careful design work.

As a much easier and immediate path, it’d be worth trying to achieve the original goal without getting into that part of the problem, so looking into in-snap bundling, content interface, classic snaps, etc.

chrmod · May 10, 2017, 9:40pm

An attempt to host multiple apps in single snap works just fine:

github.com

chrmod/snap-irc/blob/master/archs/amd64/snap/snapcraft.yaml

name: irc
version: '0.1'
summary: Wrapper for weechat IRC client
description: |
  Uses mosh to manage connection to weechat session hosted within tmux.

grade: devel
confinement: devmode

apps:
  weechat:
    environment:
      LC_ALL: C.UTF-8
      WEECHAT_EXTRA_LIBDIR: /snap/irc/current/usr/lib/weechat
    command: weechat
  tmux:
    command: bin/tmux
    environment:
      WEECHAT_EXTRA_LIBDIR: /snap/irc/current/usr/lib/weechat
      LC_ALL: C.UTF-8

This file has been truncated. show original

I’ve found another details the matches the discussion.

Running irc.tmux this snap on Ubuntu 17.04, makes it able to run other snaps installed on the system.
Running same app on UbuntuCore, make tmux confined in a sandbox, which not only exclude own apps from path, but also make them to exit with:
support process for mount namespace capture exited abnormally.

What is this difference in confinement between Ubuntu and UbuntuCore?

jdstrand · May 25, 2017, 9:11pm

There shouldn’t be any difference with Ubuntu classic distribution or Ubuntu Core in terms of the underlying confinement technologies and how snaps are confined. snapd on classic distro does have a few extra interfaces (eg, like x11, etc), but these details don’t affect your snap, which only plugs ‘home’. Importantly, your snap is using ‘devmode’ and @zyga-snapd has worked to make devmode snaps capable of executing commands in /snap/run, but strict mode does not support this.

That said, I took a look at this with Ubuntu 16.04 LTS, Ubuntu 17.04 and Ubuntu Core series 16 with core r1689. I then did in each (following https://github.com/chrmod/snap-irc):

# Ubuntu Core
$ snap version
snap    2.24
snapd   2.24
series  16
kernel  4.4.0-71-generic
$ sudo snap install hello-world
$ sudo snap install irc --devmode --edge
$ irc.tmux
$ /snap/bin/hello-world
support process for mount namespace capture exited abnormally

# Ubuntu 16.04 LTS
$ snap version
snap    2.25
snapd   2.25
series  16
ubuntu  16.04
kernel  4.4.0-78-generic
$ sudo snap install hello-world
$ sudo snap install irc --devmode --edge
$ irc.tmux
$ /snap/bin/hello-world
hsearch_r failed for |S_IFREG: No such process

# Ubuntu 17.04
$ snap version
snap    2.25+17.04
snapd   2.25+17.04
series  16
ubuntu  17.04
kernel  4.10.0-21-generic
$ sudo snap install hello-world
$ sudo snap install irc --devmode --edge
$ irc.tmux
$ /snap/bin/hello-world
hsearch_r failed for |S_IFREG: No such process

The hsearch_r issues have to do with the fact that 2.24 does not support snap-confine re-exec, but if I upgrade the core snap to r2025 (sudo snap refresh core --edge) and reboot, then we see something different:

# Ubuntu Core
$ snap version
snap    2.26.3+git212.34125a5~ubuntu16.04.1
snapd   2.26.3+git212.34125a5~ubuntu16.04.1
series  16
kernel  4.4.0-71-generic
$ irc.tmux
$ /snap/bin/hello-world
support process for mount namespace capture exited abnormally

# Ubuntu 16.04 LTS
$ snap version
snap    2.26.3+git212.34125a5~ubuntu16.04.1
snapd   2.26.3+git212.34125a5~ubuntu16.04.1
series  16
ubuntu  16.04
kernel  4.4.0-78-generic
$ irc.tmux
$ /snap/bin/hello-world
Hello World!

# Ubuntu 17.04
$ snap version
snap    2.26.3+git212.34125a5~ubuntu16.04.1
snapd   2.26.3+git212.34125a5~ubuntu16.04.1
series  16
ubuntu  17.04
kernel  4.10.0-21-generic
$ irc.tmux
$ /snap/bin/hello-world
Hello World!

So, once everything is up to date, the classic distro operates the same. I believe that Ubuntu Core is not behaving the same because its kernel is out of date. IIRC there were bugs surrounding the work @zyga-snapd did to make devmode snaps capable of executing other snap commands and I don’t think the fixes are in the pc-kernel that is available for Ubuntu Core. Perhaps @zyga-snapd can comment further.

zyga-snapd · May 26, 2017, 5:44am

Yes, this looks correct. I can check which kernel version contained the fix (my rusty memory says that it was -77 but I could be wrong).

ryanjyoder · December 6, 2017, 8:27am

I had a similar problem that I needed tmux for. My solution was to open a tmux session and then ssh’d back into the pi. Sorta cumbersome, but works for me.