=== chihchun_afk is now known as chihchun === vincent is now known as Guest97747 === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [07:49] o/ [08:33] didrocks: hey, can you have a quick look at https://github.com/ubuntu/snappy-playpen/pull/11 ? Thanks :) [08:34] davidcalle: can you expand a little bit what you are trying to fix? [08:35] ah, the Testing atom/parts/plugins [08:35] because we have a custom plugin [08:35] so subdir [08:36] davidcalle: I think that can be done maybe in an easier way (don't like the double xargs) [08:38] didrocks: sure, note that if you just strip the second dir, you end up with duplicates, that was the shorter diff I could come up with :) [08:40] didrocks: also, not sure if you have noticed, but travis is trying to apt-get an older rev of a package, hence, all runs are failing since a couple days. (https://travis-ci.org/ubuntu/snappy-playpen/builds/133371927#L544) [08:40] davidcalle: it's because I'm using sergiusens docker [08:40] davidcalle: let me set up ours + daily refresh [08:40] davidcalle: I'm playing with the regexp :) [08:42] davidcalle: got it in a way shorter, do you want me to setup a branch you can review (or pull or whatever)? [08:43] didrocks: I'm fine with your branch replacing this one === chihchun_afk is now known as chihchun [08:49] davidcalle: mind reviewing? https://github.com/ubuntu/snappy-playpen/pull/14 [08:52] didrocks: hah, wfm :) [08:53] davidcalle: we should specialized those changes in ci-run btw :) [08:53] didrocks: although... look at the ci-run :D [08:53] davidcalle: yeah, it tries to run on the top_dir [08:53] which was already the case [08:53] Let me try to special-case this [08:54] didrocks: nope, yours considers the ci-run file as a folder [08:54] davidcalle: yeah, because it doesn't care of file type [08:54] we can just say "if file type == file" -> change is in the root dir [08:55] I guess that's the best fix for other files in root [08:57] davidcalle: refresh (see second commit) [08:59] didrocks: ty :) [09:00] davidcalle: thanks for spotting it! [09:01] davidcalle: so, I guess having our own docker image refreshed daily makes sense, right? [09:02] didrocks: sounds like a good solution, yes === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [09:30] davidcalle: ok, master have most of the tests passing with my image (which is daily built) [09:30] davidcalle: however, unsure who did merge ffmepg, but it seems to fail [09:31] davidcalle: I'll push the docker image change first, then, we can iterate to get other fixed [09:42] popey: ^ [09:42] Thanks didrocks [09:45] eh? [09:46] I did ffmpeg as a standalone snap. [09:46] davidcalle merged them [09:48] popey: was just a heads up in case you had a fix. didrocks, do you have a log for ffmpeg? The original pr was fine afair. [09:50] my snap worked fine, what did you do? :) [09:51] davidcalle: I did a local ci-run [09:51] it seems snapcraft can't find the ffmepg command (which is in bin/ffmepg) [09:51] note that this can be an upstream issue with latest snapcraft :) [09:54] popey: davidcalle: I did request cron enablement as well on Travis to build master regularly (the API token method don't work, despite saying success) [09:55] ok [10:51] hello, I new to snappy and would like to know how can I monitor the the size of the update of my snap. I run a lot of sensors over 3G and the amount of data transfered is really important in my case === vejmarie_ is now known as vejmarie === JanC is now known as Guest93383 === JanC_ is now known as JanC [12:40] can anyone shed some insights on this? would be greatly appreciated :) http://gamedev.stackexchange.com/questions/122197/how-do-i-create-an-ubuntu-snap-for-a-monogame-application [12:42] Hello. Are config interfaces back or still not? [12:42] not yet [12:44] ogra_: is there some issue on launchpad for that? I did not find one :-( [12:46] sborovkov: you're right, there is none: please file one https://bugs.launchpad.net/ubuntu/+source/snapd [12:48] Understood, thanks. [12:48] hathor008: the issue is in your snapcraft.yaml [12:48] you have: [12:48] files: [12:48] "*": [12:49] you need: [12:49] files: [12:49] "*": '.' [12:49] hathor008: but please, file a bug against https://bugs.launchpad.net/ubuntu/+source/snapcraft as the error message isn't obvious [12:49] lol that's all it is? i figured it was something simple like that [12:49] ok no problem [12:50] hathor008: please copy your invalid snapcraft.yaml and mention "copy plugin" :) [12:50] but yeah, that's all ;) [12:50] * didrocks still thinks that the copy plugin shouldn't require a files: parameter for such cases "copy all" [12:55] hey guys,is there any known issue with running an OpenGL-using snap on proprietary graphics drivers? [12:56] someone trying to run a Krita snap on proprietary nvidia is gettign this: http://pastebin.com/WsUfEj8J [13:00] sergiusens: kyrofa: ^^ any help? [13:03] tyhicks: hey [13:06] Hi got a little problem with my snappy. is the tmp of the installation limited? error: cannot copy request into temporary file: write /tmp/snapd-sideload-pkg-130544461: no space left on device [13:08] thanks for your help, didrocks. i really appreciate it :) [13:08] hathor008: yw! :) [13:09] Hello. What's the current status of syslog on snappy? Is there some interface so that snap can configure it? Or how would I go about it when I need to configure it remotely? [13:11] sborovkov: you have a log-observe interface, maybe give it a shot? (I don't think there anything for configuring it remotely yet) [13:12] tyhicks, sergiusens, sborovkov: hey, fyi, in my experience access to /proc//mounts is almost always non-fatal (unless you are a disk usage analyzer or something). this constitutes a potential information leak, which is why it is not in the default profile (and in mount-observe) [13:14] sergiusens, sborovkov: fyi, tyhicks and I have been giving some thought to silencing logging of noisy denials [13:15] didrocks: thanks [13:15] jdstrand: is there a way to know what denial would be fatal? [13:15] sergiusens, sborovkov: we can do that now with an explicit deny of course, but that doesn't always work the way you want [13:15] jdstrand: since in the same log I had ldconfig run... I have no idea why, and don't know if it's fatal as well [13:15] sborovkov: run it in strict mode and see if your program runs ok [13:17] jdstrand: my program accesses /dev/vchiq as well, so it does not work in strict :-) [13:17] jdstrand: davidcalle is helping me debug the krita snap with snappy-debug.security scanlog, but he gets this: http://paste.ubuntu.com/16863706/ [13:18] Installing snappy-debug with --devmode helped http://paste.ubuntu.com/16863781/ [13:20] mhall119: jdstrand: confirmed, everytime an exception is raised, getting the stacktrace as well [13:29] what can I do with a snap thats not fits in the temporary dir while installing? [13:30] noizer: hmm? [13:30] noizer: how big is it? [13:30] noizer: report a bug first please [13:30] noizer: is your /tmp a tmpfs? [13:31] zyga: its my /tmp [13:32] zyga 250mb [13:32] zyga ps how can i manually make a snap? [13:33] zyga its for my armel build [13:33] and your HDD doesnt have 250MB free ? [13:33] (in /tmp) [13:33] noizer: just use mksquashfs [13:33] sborovkov: add '/dev/vchiq rw,' to /var/lib/snapd/apparmor/profiles/snap.your.app, then do 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.your.app [13:33] uh [13:33] no [13:34] use "snapcraft snap $dir" [13:34] ogra_: that's less manual but non the less true :) [13:34] (to make sure the proper options are used for mksquashfs) [13:34] :) [13:34] sborovkov: that will allow that access and let you see if the other ones are ok. I know you have a bug open on /dev/vchiq and that zyga gave comments on how the interface can move forward [13:35] zyga ogra_ http://paste.ubuntu.com/16864020/ [13:35] here you can see my diskspace [13:36] mhall119: that is the same error that we discussed last week. I submitted a PR to the log-observe interface and it was committed. it will be in the next snapd release [13:36] noizer, well, /tmp is a tmpfs ... so buy more ram or change that to use the disk instead [13:36] heh its my raspi [13:36] jdstrand: yup, for now he's got snappy-debug working in devmode [13:36] oh, you are *on* snappy [13:36] which revealed a syscall to 'bind' that was blocked [13:36] mhall119: let me find the commit and I can give you a workaround. yes, --devmode will work ok. when snapd 2.0.6 is out, it shouldn't be needed [13:36] ogra_: yes ofc [13:37] so running krita in --devmode gets it working for davidcalle [13:37] hmm [13:37] but someone else is having issues with OpenGL still, and running krita in --devmode doesn't help him [13:37] davidcalle is using open-source gpu drivers, and the other guy has proprietary nvidia [13:37] mhall119: 774d721b0d4935fcdcb1146b8e38396eca67c17f (for snappy-debug) [13:38] mhall119: opengl is a mvo/zyga thing (iirc) [13:38] mvo: zyga: can you guys help me debug this: http://pastebin.com/WsUfEj8J [13:38] noizer, thats a tricky one indeed [13:39] mhall119: don't forget the socketcall workaround on i386. whoever hit that traceback you pasted likely will need to add socketcall to /var/lib/snapd/seccomp/profiles/snap.krita.... [13:39] it's not a confinement issue, he's run krita in --devmode and it has the same error, and snappy-debug.security scanlog doesn't show anything before the krita launch fails [13:39] mhall119: is that a nvidia (proprietary drive) system? or what HW do you use? [13:39] noizer, and i guess worth a bug to tell snapd to use its own TMPDIR on disk ... as zyga said, file a bug [13:39] jdstrand: he's on amd64 [13:39] mhall119: not confinement> yes, I know, hence comment regarding mvo/zyga [13:39] jdstrand: though I suspect that socketcall might be related to the bind denial that davidcalle sees [13:40] mvo: proprietary driver, yes [13:40] ogra_: Is there for now a workaround? [13:40] mhall119: re bind> maybe. might just need network-bind [13:40] mhall119: do you happen to know what version? [13:40] snappy-debug in devmode will help you decide [13:40] jdstrand: yeah, but it's a digital painting program, I don't see why it would need that in the first place [13:40] mvo: of what? [13:40] noizer, not that i know of ... ou could try remounting /tmp at runtime to disk manually but i guess that will break some bits that currently use the tmpfs /tmp [13:41] mhall119: it is surprising what apps not designed for confinement require [13:41] mvo: let me get him in this channel, so I'm not passing messages around [13:41] mhall119: is that a system you have direct access to? what is the output of "ls -ld /usr/lib/nvidia-*" ? [13:42] mhall119: it could also be a kde think. bind is needed for binding to the server side of a unix socket too [13:42] thinkg* [13:42] err [13:42] thing* [13:42] mvo: I don't, which is why I'm trying to get him to join in here [13:42] mhall119: kde has this whole ipc infrastructure which I predict it going to be challenging [13:42] mhall119: or tell me where he is and I join there, either way is fine [13:42] jdstrand: hmmm, maybe. I can add network-bind to see if that allows davidcalle to run without --devmode [13:43] mvo: he's in #krita [13:43] mhall119, do you know what computer he has? [13:43] nick is mattiasw [13:43] kyrofa: only that it's amd64 and proprietary nvidia driver [13:43] Okay [13:45] zyga, do you know anything about https://askubuntu.com/questions/779875/cant-download-the-snap-packages ? [13:47] kyrofa: swift is down [13:48] impacted CI and the store [13:48] impacting* [13:48] (and hey!) [13:48] didrocks, oh. I guess that would do it! :P [13:48] didrocks, hey! [13:48] didrocks, that might also explain why my integration tests are having issues [13:49] kyrofa: not for your local test run though :p (j/k) [13:50] ogra_: What is the difference between meta/snap.yaml and snapcraft.yaml [13:54] noizer, meta/snap.yaml is what snapd itself requires inside the snap itself [13:55] noizer, snapcraft.yaml is the "recipe" you give to snapcraft that tells it how to put the snap in question together, and it creates the meta/snap.yaml for you [13:56] noizer, what kyrofa said :) [13:57] kyrofa: looking [13:57] Sorry zyga, didrocks informed me that it was likely a temporary store issue [13:59] hmmm ok but I can't snap my snap with snapcraft. So told me a few days earlier too snap it manualy but ... I don't understand it anymore [14:00] kyrofa: I also replied: http://askubuntu.com/questions/779875/cant-download-the-snap-packages/779917#779917 [14:00] zyga, ah, good idea === chihchun is now known as chihchun_afk [14:09] tedg, looking at the unity8 lifecycle thread -- it's not just saving state, but also having apps that understand they will be frozen when not focused. So apps need to use the correct Touch apis to do background stuff, etc. [14:11] mhall119: do you know why the icon shows as a piece of paper for krita? [14:11] I have made a snap and I wonder if perhaps the meta/gui/foo.png is no longer the right way to deliver an icon? [14:11] it should be...it works for me anyway [14:12] popey: is it in /snap/krita/current/meta/gui/ ? [14:13] mhall119: yes [14:14] what does the .desktop list for Icon? [14:14] Icon=${SNAP}/meta/gui/calligrakrita.png [14:14] then it should be working... [14:14] $ file /snap/krita/current/meta/gui/calligrakrita.png [14:14] /snap/krita/current/meta/gui/calligrakrita.png: empty [14:14] that won't help [14:15] zero byte file [14:15] empty? [14:15] zyga: howdy! [14:15] * ogra_ hands popey a spare byte to add it to the file [14:15] how the heck... [14:15] what copies that file? [14:15] davidcalle: can you $ file /snap/krita/current/meta/gui/calligrakrita.png [14:15] qengho: hey [14:15] mterry: Yes, I guess I see that as advanced usage. In that, they just need to know they're gonna be killed, if they want to work around that they can. [14:15] popey: it's just in the setup/gui/ folder of the snapcraft directory [14:16] setup/gui, not meta/gui? [14:16] yeah, that's the snapcraft folder, it installs to meta/gui [14:16] setup/gui jin the source [14:16] * zyga brb [14:17] k [14:17] mhall119: /snap/krita/current/meta/gui/calligrakrita.png: empty [14:17] wooot, mine works [14:17] (once I put the png in the right place) 😃 [14:17] tedg, not *so* advanced. Lots of apps assume they run in background (irc etc). But also maybe it implies a set of APIs that belong in that interface -- the download api, the push notification api, I dunno [14:17] Interfaces in Touch that let an app work in background, but the right way [14:18] davidcalle: ok, something's gone wrong with upstream's build then.... [14:18] So yes, I think those should all be in the unity8 interface. I think we might be agreeing? === davidcalle is now known as davidcalle_x86_6 === davidcalle_x86_6 is now known as davidcalle [14:19] mhall119: looks like it [14:21] davidcalle: popey: that's probably my fault in how I submitted the patch upstream [14:24] tedg, yeah yeah we agree. I was just trying to give you more ammo. Seemed like things had focused just on OOM, but background processing is another uniquely-Touch set of problems [14:25] mterry: Makes sense, I think that this first PR is more about getting hello world off the ground. We're gonna need *a lot* more work after that. But I need a foothold to start attaching things like UAL to. [14:26] mhall119: do you think you could chase our nvidia packagers to include a systemd bind mount unit from "sudo mount -o bind /usr/lib/nvidia-361 /var/lib/snapd/lib/gl/" ? [14:26] * popey shoves a dosbox snapcraft to snappy-playpen [14:26] probably the leanest snapcraft.yaml I've ever made [14:26] popey, add doom too !! [14:27] hah [14:27] mvo: I don't even know who our nvidia packagers are...is that canonical, community, or nvidia? [14:27] mhall119: tseliot iirc [14:27] mhall119, tseliot [14:27] thanks [14:27] JINX [14:27] :) [14:27] will find him [14:28] sounded a bit http://s2.quickmeme.com/img/b3/b397b33ced963be59c76e2566b24f0547aa2ae596f148ee1339f3c8e5c5b058c.jpg [14:28] heh [14:28] which seems harsh, despite it being nvidia [14:29] didrocks: your jenkins is faulty... " g++: not found" [14:29] didrocks: https://travis-ci.org/ubuntu/snappy-playpen/builds/134182006 [14:33] mvo: I assume the nvidia package fix needs to be SRU'd into 16.04's archives, it's not something that gets fixed in ubuntu-core images [14:33] mhall119: yeah, we need to get this SRUed [14:33] mhall119: not something we can fix in the image [14:34] also, in the image the driver would have to live in the kernel snap [14:34] (not in an nvidia package) [14:34] mhall119: thanks a lot for helping with the bind mount, really much appreciated [14:35] zyga, mvo: I do not remember anything in particular, but it's possible I pressed control-c during a "snap install" or "remove" before. Not to poison your debugging thoughts, but if nothing else seems obvious that might be a place to explore. [14:35] qengho: that wouldn't change anything [14:35] qengho: snapd carries the work, snap is just a rest client that says "do this please" [14:36] qengho: thanks for state.json [14:36] qengho: and for the syslog parts [14:41] qengho: can you still reproduce this issue? [14:42] qengho: and regardless, can you please pastebin the output of mount [14:42] qengho: and ls -l /snap/* [14:43] zyga: I'll try to reproduce now. mount is in the bug report already (|grep snap). [14:46] qengho: thanks [14:51] zyga: reproduced. Attached log. [14:53] Aw, man, and 2.0.3 is gone from APT. I can't downgrade now. [14:57] qengho: is there anything mounted under /snap/google-chrome/ [14:57] qengho: under the directory (not there directly) [15:00] so, if one of my parts is a collection of bash and python scripts that uses an INSTALL file, what would I specify for a plugin? Or will I have to write my own? (there doesn't seem to be a list of included plugins anywhere) [15:00] zyga: you have my full mount list. [15:00] qengho: thanks, I'll check it out after this cal [15:00] call [15:01] lsof |grep chrome [15:01] (wrong terminal. gah.) [15:02] sethj: "Uses an INSTALL file"? [15:02] sethj: I'm guessing plugin: copy [15:03] qengho, https://www.debian.org/doc/manuals/maint-guide/dother.en.html#install. copy does sound like it would be right. Lemme try. (and *is* there a list of these somewhere?) [15:04] sethj: yes. $ snapcraft list-plugins [15:04] oh very nice. [15:04] someone needs to write a manpage :P [15:07] sethj: It's also very easy to put a file in parts/plugins/sethj.py, import snapcraft, class Anything(snapcraft.BasePlugin): def build(): super().build(); self.run(["something specific to you") [15:07] sethj: in your snapcraft.yaml, that's "plugin: sethj" [15:08] I'm trying to install a snap via command line, and get the following error: [15:08] - Make snap "ubuntu-core" available to the system (cannot set next boot: cannot determine bootloader) [15:08] I'm on a RPI with ubuntu-core [15:08] netphreak: that's a known bug. Should be fixed soon. [15:09] ... hopefully :) [15:10] netphreak: subscribe: https://bugs.launchpad.net/snappy/+bug/1580403 [15:10] Launchpad bug 1580403 in Snappy "snap tries to manage bootloader in snappy-on-ubuntu-classic mode" [High,Fix committed] [15:12] netphreak: wait, "with ubuntu core"? Is that from a ubuntu core testing image, or from regular 16.04 image with ubuntu core from snapd? [15:17] Not quite sure what it is, got it setup a couple of weeks ago - don't seem to have the image file any more.. [15:17] Any command i can run to see which version? [15:18] netphreak: what's it look like to you? What do you see when you turn it on? [15:19] Does "apt" do anything? [15:19] yes.. Apt is installed [15:20] i used apt to install snapcraft and snap [15:21] zyga: i'm getting fails in the asserts section when executing run-checks, am I missing some setup? [15:23] joc_: can you be more specific please [15:24] zyga: yeah i'm running run-checks as per the README in snapd [15:24] didrocks we agreed a while ago to even deprecate `files` in the copy plugin and direct people to `filesets`, `organize`, `stage` and `snap` [15:24] zyga: it gets as far as github.com/jocave/snapd/asserts_test [15:24] zyga: then i get: [15:25] asserts/asserts_test.go:37: undefined: asserts.TestOnlyType [15:25] asserts/asserts_test.go:37: too many errors [15:26] netphreak: then you aren't using "ubuntu core", but ubuntu with snaps. And that is the bug here. snapd thinks it's the top OS, when it's not in your case and my case. And that bug is fixed in a few days. [15:27] ahh.. ok.. thx for explanation. [15:27] do you know the status of snappy classic-mode? [15:27] netphreak: "apt" doesn't exist in the Ubuntu Core world. It's a specialty-device kind of place. We get to piggy-back on all its goodness, though. :) [15:27] :) [15:27] zyga: i've only add an interace as you suggested so wasn't expecting to get errors from anywhere else [15:28] joc_: hmm, can you reproduce that on master? [15:28] joc_: anyway, ignore run-checks [15:28] joc_: just go test in interfaces/builtin initially [15:28] joc_: and open a pull request or show me your branch [15:28] tyhicks: hey [15:28] netphreak: Not much. I used it back in February, but it's probably changed a lot since. [15:28] jdstrand: hey :) [15:28] jdstrand: I wanted to sync about snap-confine [15:29] zyga: hey--ok, should tyhicks be here? [15:29] jdstrand: I think so [15:29] netphreak: it, like all of snap stuff, is in heavy development. To be released soon. [15:29] jdstrand: I have a few questions and I want to know what you are working on, e.g. if tyler will look at the bind mount interface and if you saw what's posted to the repository lately [15:29] davidcalle: didrocks https://github.com/ubuntu/snappy-playpen/pull/15 - feel free to merge if you want :) [15:30] zyga: hi [15:30] tyhicks: hey, good to see you [15:31] zyga: thanks, i'll get tests passing then get back to you [15:31] zyga: currently I am not doing anything with the launcher. I am waiting for the seccomp arg filtering reviews (I saw you commented, waiting on tyhicks too). when that is done, I will start on trying to get that into xenial and then fix various bugs blocked on that [15:31] joc_: note that for all the integration tests to pass you need the patched ubuntu-device-flash [15:31] (in your path) [15:31] jdstrand: I completed my seccomp arg filtering review friday evening [15:31] setpriority is the big one, but others. I believe tyhicks is working on other things [15:31] awesome [15:31] jdstrand: note that we should be careful about releases of the code today [15:31] I'm still behind on email and will get to it today [15:31] jdstrand: as we're getting more and more snap-run/confine/exec story landed [15:32] jdstrand: and that needs coordination [15:32] zyga: yes, I was considering SRUing something as a patch to ubuntu-core-launcher for xenial and let all the other stuff be under your control [15:32] it just depends on the timing [15:32] jdstrand: that's sounds good, just let us know when this happens [15:32] jdstrand: note that there's been an upload to debian that's not reflected in either tree today [15:33] jdstrand: (the version is +1 there) [15:33] jdstrand: ubuntu@localhost:/etc/modprobe.d/modprobe.d$ ll [15:33] I'm getting asked every day though on when bug NNN will be fixed and I keep saying 'when seccomp arg filtering is there...) [15:33] er [15:33] bad paste [15:33] jdstrand: heh [15:33] zyga: I haven't started working on the bind mount support in interfaces - despite not having the time to work on it yet, it felt like a lot of things were in flux and I wasn't clear if plans had changed [15:33] jdstrand: yes, I see that this should land as soon as we can [15:33] tyhicks: can I ask you to review my chroot / pivot_root patch [15:33] tyhicks: I suspect we'll go ahead with that approach (just polish it more) [15:34] tyhicks: but I want a solid security review to preceed that [15:34] zyga: sure, I can review that patch but I thought we were told not to make that change right now? [15:34] tyhicks: yes, but the blocker is getting done :) [15:34] zyga: is what is in the debian +1 patch at least in trunk? if not, what is that? [15:34] tyhicks: and gustavo said that it should be the next thing after that [15:34] zyga: ack - i'll have a look [15:35] jdstrand: I think slangasek uploaded something to debian and there's a change that is not integrated anywhere [15:35] other than that I'm proposing some tooling changes (autotools) [15:35] http://metadata.ftp-master.debian.org/changelogs//main/u/ubuntu-core-launcher/ubuntu-core-launcher_1.0.29+1_changelog [15:35] it's not code changes [15:36] and I will have a few small patches that make lintian happier (lots of little issues), some of those are related to security so I'll poke you specifically on github [15:36] jdstrand: with native packages it is hard to see [15:36] zyga: if it's lintian, see slangasek's patch [15:36] jdstrand: perhaps I should just ask slangasek to send that to snap-confine :-) [15:36] slangasek: ^^ [15:36] :) [15:37] tyhicks, jdstrand: are you both aware of what's changing to snap-run/confine/exec now? [15:38] zyga: no, I'm not fully aware [15:38] not really, no [15:39] okay, so the quick big picture is that snap run (a new subcommand of snap) will run snap-confine (which is the current C codebase), that will apply process confinement as it does today and then execute /usr/lib/snapd/snap-exec (xi style) which will in turn read all the yaml bits and figure out what to exec [15:40] that last program (snap-exec) will be written (is written by mvo actually) in go and will mainly do yaml parsing and environment setup [15:40] I just want to keep both of you in the loop so that you're aware of what is going on [15:41] zyga: xi style? [15:41] he means ix [15:41] yes [15:41] sorry [15:41] not changing the profile [15:41] I see [15:41] so snap-exec runs as the final application will [15:41] one thing we will get out of that is that snap-exec will also know how to run pre commands, post commands, and hooks [15:41] and that it will no longer have to get the command to run from command line, instead command line will just be the actual command line for the application being started [15:42] FWIW, I don't think snap-exec should run under the confinement of the application [15:42] it sounds like it'll be doing things that the application should not have access to do [15:42] but maybe I'm wrong [15:42] tyhicks: it will only read snap.yaml [15:42] tyhicks: and exec the executable of the application [15:43] zyga: you said pre/post commands and hooks [15:43] tyhicks: those are just commands to run that are written down in snap.yaml [15:43] so, instead of snap-confine exec'ing the binary, it executes snap-exec which executes the binary [15:43] tyhicks: e.g. snap run apache --command=post [15:43] jdstrand: yes [15:43] tyhicks: and that goes and reads what to really execute from snap.yaml [15:44] tyhicks: so that we don't have to pass it on the command line all the time [15:44] this approach also kills a lot of the wrappers [15:44] jdstrand: this is good - it moves code out of the setuid root launcher and the launcher won't need to learn how to read yaml [15:44] the long version is here: https://docs.google.com/document/d/1Afjs72T43nN0J5DK6qiaKmIthOjhK8_bvrac6E56Bcc/edit# [15:44] zyga: what is the motivation for this? does it provide snap-confine cleanups? (if so, what?) does it allow use to clean up other parts of the system? (if so, what?) [15:44] to the point that we may end up having no wrappers (and /snap/bin might just contain symlinks to /usr/bin/snap [15:44] jdstrand: it unlocks hook [15:44] hooks [15:44] tyhicks: yeah, the u-c-l (snap-confine) really now only needs to deal with the essential stuff, everything else is done in go [15:44] sidesteps environment [15:44] so that we can cleanly set environment for the process [15:45] and makes launchers mostly redundant [15:45] ah, that doc is helpful [15:45] is it up to date? [15:45] I hope the environment stuff isn't the main motivation [15:45] tyhicks: I don't actually know, I think the main motivation is to clean up the command line part [15:45] I'm about to SRU the apparmor changes that would allow the launcher to set up the environment [15:45] so snap run looks nice [15:45] tyhicks: it sounds like hooks is the price of admission [15:45] as do all the things after that [15:45] jdstrand: its up-to-date to the point of "previous dicussion" [15:46] zyga, kudos to your post about first contribution to snapd <3 [15:46] zyga, maybe you can try to get the people at https://twitter.com/yourfirstpr to tweet about it [15:46] ara: :-) when I saw that bug I just said "this has to be something other people can contribute" [15:47] ara: will do [15:49] tyhicks, jdstrand: that's all I had [15:49] I think you are in the loop now :) [15:49] tyhicks: so, I think in terms of security, this is good, if a little twistier. it reduces the number of lines of setuid code a bit [15:50] but the setuid code is at least not twistier [15:50] jdstrand: reducing the amount of code in the setuid launcher's address space is a good thing [15:50] tyhicks: what was the env bits to the launcher you were talking about? the safe/unsafe stuff? [15:51] jdstrand: also, this alleviates the launcher from needing to continually expand to do more things (stuff can go into snap-exec) [15:51]