On Fri, 2017-02-10 at 14:44 +0100, Roberto Mier Escandón wrote: > That's interesting, Simon. Good idea having available both $SNAP_DATA > and /media. We'll do. > > But now, let's back to original topic: chroot into snap. > After solving the issue Thomas found related with the path of the > document, I see now there are two operations not allowed in strict > confinement: mknod and chroot. Here is what the snappy-debug.security > log shows: > > = Seccomp = > Time: Feb 10 12:31:31 > Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=31983 comm="loolkit" > exe="/snap/loolwsd/x16/usr/bin/loolforkit" sig=31 arch=c000003e > 133(mknod) compat=0 ip=0x7f6a6d6450fd code=0x0 > Syscall: mknod > This is in progress: https://github.com/snapcore/snapd/pull/2749
> = Seccomp = > Time: Feb 10 12:31:42 > Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=11048 comm="loolkit" > exe="/snap/loolwsd/x17/usr/bin/loolforkit" sig=31 arch=c000003e > 161(chroot) compat=0 ip=0x7fd0178dfb47 code=0x0 > Syscall: chroot > This may be tricky as the paths > I've solved that by plugging docker-support and all works fine. But that > interface gives a lot of permissions, and the name maybe is not the most > accurate for a case like this. The docker-support interface should not be used for this. It is a so called 'super-privileged' interface and like you said, grants way more than is needed. > Shouldn't we have an interface allowing mknod, chroot and maybe ptrace > for snaps creating their own chroot jails?. As said, mknod is in progress. Can you file a bug for chroot? ptrace we could allow with 4.8+ kernels or if we add 'seccomp after ptrace' to the list of kernel patches for snappy. -- Jamie Strandboge | http://www.canonical.com
signature.asc
Description: This is a digitally signed message part
-- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
