=== JamesTait is now known as Guest2387 === devil is now known as Guest83087 === Guest83087 is now known as devil__ === dasjoe_ is now known as dasjoe === devil is now known as Guest51142 === tsimonq2alt is now known as tsimonq2- === tsimonq2- is now known as tsimonq2 === chihchun_afk is now known as chihchun [07:04] I just uploaded a new version of lxd to the store, no change to policy, would be nice if it could go through soon, we've had a few folks complaining that 0.21 was a bit dated (by about 6 months :)) [07:04] jdstrand: ^ [07:41] good morning [07:41] good morning dholbach [07:48] salut didrocks [08:05] good morning! [08:33] How can I see that my custom seccomp and apparmor file is applied to my snap? [08:59] jdstrand: can I see that my custom seccomp and apparmor file is applied to my snap? === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [09:18] willcooke, dpm: good news, the most recent snappy upload to xenail (should hit xenial-proposed with the next publishing) will have unity7 integration, i.e. nothing (hopefulyl) more to do. install cap-test and it will show up in dash searches etc (make sure you restart your session once after updating snappy because it installs a Xsession.d file for this). I'm very excited! [09:19] mvo \m/ [09:19] mvo, thank you!!! [09:19] Trevinho, ^^ [09:19] mvo, awesome! I just managed to upload calculator to the store, for which I included the .desktop file support. I'll go ahead and test that too! [09:19] just literally a few minutes ago [09:20] so I'll give unity 7 integration a spin once I see the new snappy package in the archive [09:23] dpm: yeah, xenial-proposed, there is a build failure on powepc that I look at next so it won't promote right away [09:23] ok [09:23] dpm: but you can directly grab the two debs from LP if you are eager to test :) [09:23] dpm: plus the updated ubuntu-core-launcher but that will come as a normal update [09:24] mvo, thanks. I am eager :), but I think I'll wait if it's just a matter of hours, which might save me some extra fiddling [09:26] o/ [09:27] noizer: yes, look at /var/lib/snappy/{apparmor,seccomp} [09:27] dpm: you are eager and WISE at the same time :) [09:27] lol [09:30] zyga: ok i was looking at the correct files but with security-policy it doesn't work. http://pastebin.com/DmAdrhU3 [09:36] zyga: do you have any clue why my apparmor and seccomp files doesn't apply to my snap? [09:37] mvo, how do updates to the ubuntu-core snap happen on the desktop? It is a bit like magic to me. I've tried "sudo snappy upgrade ubuntu-core" a few times and it tells me there are no new versions. Yet every now and then I see it updated automagically when I run "snappy list --verbose". So I'm not sure if this is something that needs to be manually maintained (and how?) or is autoupdated [09:37] noizer: s/slots/plugs/ -- use the lastest released snapcraft (just released yesterday AFAIR) and it should work [09:37] noizer: good luck [09:37] noizer: sorry about the swap, it's stabilizing now [09:37] Just switch between slots and plugs? [09:37] noizer: you'll have access to many useful interfaces next week (+1/-1 image release) [09:38] ye0 [09:38] yes [09:39] But to be honest i think i need an unconfined snap just for my thing. So i try to make it by changing the apparmor and seccomp file [09:42] mvo: great to hear [09:50] zyga ok thx with plugs it works to edit the apparmor just need to see that mine apparmor is correct but now it fails [09:52] noizer: sorry, I don't get the last part ;; what failed? [09:56] wait i got the following error when I'm installing my snap with a custom apparmor [09:57] zyga: error, unexpected TOK_ID, expecting TOK_END_OF_RULE [10:01] zyga: thats an error of mine apparmor [10:02] noizer: yeah, I think your apparmor is just wrongly spelled [10:02] noizer: btw there's an unconfined template that you can reference [10:03] noizer: look at your desktop [10:03] ah, snapcraft has been updated yesterday with the plugs/slots switch o/ [10:04] cool [10:04] noizer: dpkg -L ubuntu-core-security-apparmor [10:04] ysionneau: yep [10:48] hmm would there be any interest in chrooting into $SNAP (after doing some bind mounts) ? [10:48] I mean, before running an app [10:48] ysionneau: why? [10:48] that would for instance allow the app to use hard coded absolute paths [10:48] ysionneau: and not allowed to do many other things [10:48] ysionneau: I don't think this is needed [10:49] this could be useful for some apps I think, so that you don't have much work to "port" them to snappy [10:50] instead of having to rewrite lots of code [10:50] i doubt chroot will be allowed by seccomp [10:50] That could be an option in the snapcraft.yaml like "chroot: yes" [10:52] bu tthat doesnt stop you from shipping a full rootfs if you want and bend the env to completely use it [10:52] which would be close to a chroot [10:54] what do you mean by "bend the env" ? [10:54] I'm not sure there is a trick to allow an app to write to "/var/lib/" [10:54] other than chrooting [10:55] well, pretty much what the ubuntu-core-launcher does already but also make it use the shipped toolchain, linker, libc [10:55] or maybe an LD_PRELOAD to hook open() [10:56] as long as $SNAP and $SNAP_DATA are on the same device you might be able to use hgardlinks for writable bits and dirs [10:57] but, whatever I do, /var/lib/ will stay read-only [10:58] that's my main issue [10:58] change it to ./var/lib then :) [10:59] (indeed that might mean to recompile the world ... i didnt say its easy ;) ) [11:01] the thing is, there are lots of occurence of this type of issues in the different softwares I want to "port" to snappy [11:01] so I'm not a big fan of this solution [11:01] (by solution here I mean pushing fixes in the code everywhere to use env VAR instead of hard coded absolute paths) [11:02] indeed ... [11:02] dont you need to just re-do the linker path though ? [11:04] zyga: the unconfined template can he make some calls to /snaps/bin/... ? [11:04] noizer, unconfined apps have all the power a natively installed deb would have [11:05] so he can exectute all things? [11:05] 12:02 < ogra_> dont you need to just re-do the linker path though ? < I'm talking about normal "open()" here, not library paths issues [11:05] (its just the paths and workdir that are different then ... ) [11:05] or maybe I don't understand what you propose :o [11:05] oh, open() in your code, i see [11:05] well, if you cant get around that one, you can always use lxd or docker [11:06] ah, interesting! [11:06] that equivalent to a chroot i'd say (just a bit more secure) [11:06] thanks! [11:06] will think about that :) === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [11:26] noizer: maybe not [11:26] noizer: it's not so simple [11:26] noizer: you cannot change aa profile anyway *AFAIR* [11:27] zyga: do you mean with AFAIR [11:27] noizer: as far as I remember [11:27] noizer: it's not identical to really unconfined [11:27] noizer: but it very broadly permissive [11:28] zyga: What I now did is took an empty apparmor and try to execute an binary from /snaps/bin/ [11:28] I see it is then possible to execute the binary [11:29] zyga: But then i see the following error: [11:29] error: /bin/sh: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory [11:29] noizer: I don't think that will work [11:30] noizer: try doing what I said [11:30] noizer: use old-security and unconfined template [11:30] ok [11:31] zyga: then i should be able to execute the binary? [11:32] zyga: got then following error: aa_change_onexec failed with -1. errmsg: Permission denied [11:39] noizer, why didnt you fiollow jdstrand's advise from yesterday ? [11:39] *advice [11:39] noizer: that's exactly what I said [11:39] noizer: you cannot change aa profiles [11:39] ogra_: what was the advice? [11:40] zyga, i gave him an existing (outdated) unconfined snapcraft.yaml and jamie gave all hints to adapt it to the new interfaces setup [11:41] there is no need to fiddle with apparmor files [11:41] ogra_: i suspect that unless there were explicit changes somewhere you still cannot (even unconfined) run other snaps from your snap [11:42] why not ? [11:42] ogra_: it's not allowed, even for unconfined programs (that are really confined but broadly permissive) [11:42] unconfined has the same powers as a deb ... just that all paths and the workdirs are completely mangled [11:42] ogra_: I went through this issue a few times [11:42] ogra_: nope [11:42] ogra_: that is not true [11:42] i have an unconfined debootstrap that woprks just fine [11:42] ogra_: unconfined still gives you aa profile and seccomp profile and a cgroup for devices [11:42] ogra_: it's not the same as running from the ssh shell [11:43] i dont see why an unconfined systemctl shouldnt be able to control services for example [11:43] ogra_: because that's what's spelled out in unconfined, we'd have to make super-unconfined that has extra powers [11:43] ogra_: FYI I'm not arguing with you; I'm just telling you how it really works today [11:43] so unconfined changed ? [11:43] ogra_: no, it was always like that [11:43] with the last iteration [11:43] ogra_: unconfined != not confined in practice [11:44] right [11:44] ogra_: it was like that in 15.04 [11:44] ogra_: and I suspect still is in 16.04 [11:44] well, unconfined in 15.04 lets me do everything with my system [11:44] i dont think your seccomp assumption is true [11:44] ogra_: it's 100% true for aa [11:44] but aa wont be used in unconfined [11:44] ogra_: you cannot load another aa profile while running unconfined profile [11:45] ogra_: it _is_ [11:45] ogra_: 100% guaranteed it is [11:45] ogra_: we've been through this many times in cert [11:45] you can not load another aa profile because aa_exec isnt in use at all [11:45] ogra_: I don't think this is true, in any case, as unconfined snap, you cannot run other snap's apps [11:46] no, but youz can run thes system systemctl [11:47] ogra_: sure but the error that noizer saw is exactly what I was describing [11:47] ogra_: not related to systemctl [11:49] dpm, so snapcraft seems to do just what click-review expects: [11:49] snapcraft/commands/snap.py: mksquashfs_args = ['-noappend', '-comp', 'xz', '-all-root', '-no-xattrs'] [11:51] and for snappy it's http://paste.ubuntu.com/15340831/ [11:51] the latter seems to miss "-all-root" [11:52] that was in snap/squashfs/squashfs.go, but in obj-x86_64-linux-gnu/src/github.com/ubuntu-core/snappy/pkg/snapfs/pkg.go it has the "-all-root" option [11:53] mvo, is there a reason that in one of the mksquashfs incantations the "-all-root" option is missing? [11:53] dholbach: (mvo went for lunch, may reply with lag) [11:53] dholbach, then perhaps an issue in click-review-tools? As I built the app with snapcraft, and I *think* LP does it with snapcraft as well [11:54] zyga, thanks [11:54] dholbach, --all-root means that all your files are chowned to root inside the squashfs ... probably not wanted in all cases [11:54] dpm, it might, yes [11:55] (definitely not for os snaps for example) [11:55] dpm, I just thought I'd check all incantations first :) [11:55] makes sense, thanks dholbach :) [11:56] zyga: So as conclusion it is not possible at all what I want even when i get my custom aa? [11:57] zyga: or does i understand it completly wrong? [12:01] noizer: you'd have to talk to jdstrand and ask if it is possible to use a custom template to unlock running other snaps from "unconfined" snap [12:02] noizer: technically it is possible, it's just the matter of having the right template or the right extra bit in an existing template [12:02] noizer: but jdstrand will know how (though he's super-busy so you might not get a quick answer) [12:05] jdstrand, I'm still seeing http://paste.ubuntu.com/15340881/ - do you know what the issue is? [12:06] that's with r605 [12:17] dpm, it might be https://bugs.launchpad.net/ubuntu/+source/click-reviewers-tools/+bug/1555305 [12:17] Launchpad bug 1555305 in click-reviewers-tools (Ubuntu) "resquashfs test fails if snap has symlinks" [High,Confirmed] [12:18] http://paste.ubuntu.com/15340912/ is what I tried [12:18] http://paste.ubuntu.com/15340914/ was the result [12:19] dpm, so it sounds like it's a known problem with snaps containing symlinks(?) [12:19] the mksquashfs arguments cited in the error message might be a red herring [12:26] Good morning! [12:28] hey kyrofa [12:28] lool, looks like you pinged me yesterday, you around? [12:28] Hey dholbach, how are you? [12:28] good good - how about you? :) [12:31] Not bad! Been out the last few days, felt nice [12:32] Though now I have ~300 emails to slog through [12:33] good luck with those :) [12:35] dholbach, weird, as the errors weren't triggered with the first rev1 upload [12:36] thanks for digging it out [12:36] dpm, let me doublecheck - it could be that click-reviewers-tools didn't have the check at the time :-) === chihchun is now known as chihchun_afk [12:40] ok! [12:42] dpm, looks like the old snap has the same problem [12:42] strange, no errors were triggered on the rev1 upload [12:46] zyga: ok so I don't need to change the apparmor from my snap because there are some other things thats needs to be done? [12:55] noizer: no, you didn't understand what I said; I think it *is* possible technically but you have to figure out the right aa syntax by youreself [12:56] noizer: I don't know how to do this FYI [12:56] zyga ok thx in advance [13:11] mvo, http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ ... done ... all os and kernel snaps are now published there [13:12] (now onward to creating the dragonboard kernel.snap ... ) [13:19] dpm, sorry didn't see your reply... as I said earlier: I think back when you uploaded rev1, click-reviewers-tools probably didn't have this check - it was added quite recently [13:20] dholbach, ah, thanks. I had seen it, but somehow I hadn't connected the two. I'll blame it to multitasking rather than admitting I misread it :) [13:20] no worries :) [13:21] I just checked - there were 9 days between the uploads - an eternity in snappy's world :-P [13:23] ogra_: nice [13:23] * ogra_ tries a test build [13:24] ubuntu@localhost:~$ snappy list [13:24] Name Date Version Developer [13:24] canonical-pc 2016-02-02 3.0 canonical [13:24] canonical-pc-linux 2016-03-10 IOTfGNaBRCTJ sideload [13:24] ubuntu-core 2016-03-10 IOTfGOFdgPKF sideload [13:24] boots :) [13:24] dholbach: that are the 9 days in which we rewrote it in hylang [13:25] mvo, good to hear you're focusing on the important stuff :-P [13:26] hylang ? not perl ? [13:27] hmm, webdm still not proted to interfaces ? [13:29] funny how all snaps are pretty exactly 20MB smaller than their tarball equivalents ... that seems to be constant, not actually a percentage or anything [13:43] hello, I'm new here [13:44] hello techraf [13:44] Hey techraf, welcome! [13:44] I was trying to create example snaps -> with snapcraft 2.0 I could "snapcraft snap" and had .snap in result [13:45] the same "snapcraft snap" 1.0 does not produce anything [13:45] at least it does not create .snap [13:45] techraf, right, the command-line is a little different in 1.x [13:45] techraf, try just `snapcraft` [13:46] techraf, the actual step in 1.x is called "assemble," but calling snapcraft with no arguments is equivalent [13:46] snapping... [13:47] techraf, `snapcraft --help` might be useful [13:47] techraf, compare the output between versions, you'll see similarities [13:48] will do, success so far [13:48] you helped me much, thank you [13:49] techraf, any time :) [13:50] jdstrand: hey [13:51] jdstrand: I've send you a ping on github for a code review [13:51] jdstrand: it's not urgent but I'd love if we could spend a moment to go over the code there [13:51] jdstrand: and ensure it's all good [13:54] didrocks, how are things going for you this week? Examples still coming along? [14:04] zyga: sure thing [14:06] dholbach: can you give me the snap? [14:08] noizer: hey, as mentioned, you are pretty outside of snappy atm and this is the snappy channel. since your questions are now of the form "how to profile with apparmor" I suggest taking a look at 'man apparmor.d' and bringing your questions up on #apparmor on oftc [14:10] noizer: also, I saw your paste and you need to use 'plugs' instead of 'slots' [14:11] noizer: be sure you are using snapcraft 2.4 [14:11] jdstrand I am using now snapcraft 2.4 [14:12] jdstrand: I am trying some things but now without any success xD [14:15] noizer: I would start with using plugs instead of slots, otherwise you get the default confinement. also, you can see what confinement is bing used in /var/lib/snappy/apparmor/profiles [14:15] being [14:16] oh, that was in the wiki page I gave you yesterday [14:17] dpm: you asked for someone to push the calculator through. did that happen? when I looked it wasn't showing up for review. if it didn't happen, can you request a manual review? [14:19] jdstrand: I saw that today and now I am using plugs. and my apparmor changes [14:19] ok good. now you are in the realm of how to profile [14:19] that is where #apparmor can help [14:20] Ok is that from snappy developers too? [14:22] noizer: that is what I was saying you should take to #apparmor on oftc [14:22] that has apparmor developers and community [14:39] jdstrand, I did a fresh checkout from c-r-t and ran ./bin/click-review on the .snap from https://myapps.developer.ubuntu.com/dev/click-apps/4630/rev/2/ [14:40] with the installed version (0.38 from xenial) it does not crash [14:41] jdstrand: thanks [14:49] mvo: are paths like this intended: /etc/systemd/system/snaps-cap\x2dtest.sideload-LSXRFfhCCLCY.mount [14:49] mvo: the '\x2d' is causing bzr (etckeeper) to crash [14:50] and it isn't clear why '-' is being escaped there and nowhere else [14:50] unless you are using '-' as a delimiter, in which case I would suggest '_', since that isn't an allowable char in the snap package name [14:51] (or some other not allowed char) [14:52] dholbach: when you checked out crt and did ./bin/click-review, did you set PYTHONPATH? if not, you need to: PYTHONPATH=./ ./bin/click-review /path/to/snap [14:53] jdstrand, oh? [14:53] since when? [14:53] always [14:53] jdstrand: sounds like misisng setup.py --develop in hacking docs [14:53] otherwise you end up using what is in /usr [14:53] hohum [14:53] dholbach: this is typical to all python code [14:54] jdstrand, dholbach helped me on this. I hadn't realized last night that I needeed to explicitly say "Request manual review". The apps are now published. We still don't know what the issue with the checksum is, but at least the published apps work as opposed to the old ones not working after the plugs<->slots change [14:54] jdstrand, confirmed [14:54] thanks [14:55] dpm: you went offline before I could respond. the checksum issue is https://bugs.launchpad.net/ubuntu/+source/click-reviewers-tools/+bug/1555305 [14:55] Launchpad bug 1555305 in click-reviewers-tools (Ubuntu) "resquashfs test fails if snap has symlinks" [High,Confirmed] [14:55] jdstrand pff there aren't many people on #apparmor [14:55] noizer: on OFTC? [14:56] dpm: I have disabled the test for now until I can fix that [14:56] ok, thanks [14:56] jdstrand: sorry did some typo [14:57] dholbach: ok, with PYTHONPATH, I can confirm it as well [14:58] dholbach: I don't recall, did you file a bug for this? if not, don't worry about it [15:00] jdstrand: I think the pats are the result of calling systemd-escape [15:04] hrm [15:04] I guess I'll file a bug against bzr and workaround it [15:08] kyrofa: hey! More busy with the developer website content. On the examples, I'm waiting for the poll feedback we launched with dholbach first to see if people like them :) [15:08] didrocks, awesome! [15:10] dholbach, how is that poll coming? I'm looking forward to seeing that myself [15:11] dholbach: oh, heh, nm, I typoed PYTHONPATH. it works fine here, so nothing to do [15:17] jdstrand: I'll dive into more coding, ping me when you have a moment to go through that diff [15:17] dholbach, do the review tools catch symlinks that point outside the snap? [15:20] kyrofa, yes [15:20] zyga-phone: yeah, haven't gotten out of email and irc pings yet [15:20] dholbach, ALL of them, no allowed whitelist or anything? [15:21] kyrofa, there's a whitelist [15:22] dholbach, oh darn, that throws a wrench into my plans. Can I have a look at that list? [15:23] hey kyrofa, you are back. I'm sorry, I assume we wouldn't have standup today. [15:23] elopio, I am indeed! And that's okay :) [15:23] I'll make it on time tomorrow. [15:23] kyrofa, http://bazaar.launchpad.net/~click-reviewers/click-reviewers-tools/trunk/view/head:/clickreviews/common.py#L631 [15:24] dholbach, excellent thank you :) [15:24] elopio, how has the week been going? [15:24] I finally made it through my emails, looks like we cranked out 2.4, nice [15:27] kyrofa: yes, thinks are looking good. I'm still blocked on the closed ports to test the http examples, but most of the tests are running now. [15:27] sergio is doing good progress on the kernel, he said it's almost ready. [15:28] elopio, yeah I just looked through it [15:29] elopio, no tests to speak of, but the code is looking pretty good [15:34] elopio, and looks like you were able to greatly speed up travis tests, eh? Needs a rebase though === ken__ is now known as kenvandine [15:43] kyrofa: yes, it's running again. [15:43] I'm sad because we are no longer running on xenial, but I hope they will just update the machine in april. [15:45] elopio, don't get your hopes up-- I think they still run on 12.04 by default unless you request trusty [15:45] elopio, I get the impression that their architecture is very tightly integrated [15:47] they are still calling them beta, the trusty machines... [15:47] but it's GCE. I see no possible way it will be different to manage a xenial in there. [15:48] I'm also sure they can prove me wrong :) [15:49] elopio, heh [16:00] is ubuntu trying to simlify the building process from source code? Is it trying to make something like "ports"/ABS-arch? [16:01] varaindemian: no [16:02] zyga, is ubuntu core a different os or is part of ubuntu? [16:03] it is a new type and setup of ubuntu (not using apt/dpkg in the runnung system, special filesystem setup, all the shiny new features of teh snappy package manager) but still ubuntu [16:04] varaindemian: http://www.ubuntu.com/internet-of-things [16:08] ogra_, so ubuntu 16.04 lts won't have the snappy sotre [16:08] store [16:08] ogra_, right? [16:08] the snappy packagemanager will be shipped in ubuntu 16.04 installs [16:08] so you can indeed use snap packages from the store [16:09] ogra_, oh, so I cna build packages for my own system right? [16:09] (on these systems thats additionally to dpkg packages) [16:09] yeah [16:09] you can use snapcraft to package up your github projects as snaps [16:09] (or whatever other projects yoou have) [16:09] ogra_, nice and the building process from source code will be simplified? [16:09] yeah, snapcraft makes that pretty automated [16:10] so cool [16:10] you create a yaml file that describes the build and just run the snapcraft tool in your workdir ... out comes a snap :) [16:12] ogra_, Really really interesting. How would that differ compared to an os that uses "ports like" system? [16:12] dunno, i never used a "ports like" system [16:13] what you deal with are binary packages though ... the store also doesnt care about source (you can even snap up complete binary blobs if you want) [16:13] snapcraft just makes it easy to create them but source isnat mandatory [16:13] *isnt [16:16] jdstrand, I'm trying to build location-service in snappy for 16.04 and it seems to want to link against libapparmor.a rather than the shared library. As best I can tell when I stage apparmor-dev in snapcraft something isn't running that sets up the unversioned .so symlink in /lib/. Have you seen this sort of thing before? === JanC_ is now known as JanC [16:17] is it that staged packages are just unpacked and no scripts or triggers are run? [16:18] ssweeny, you got it [16:18] ssweeny, they're only unpacked [16:18] ssweeny, no postinst, etc [16:18] hm [16:19] thanks kyrofa. is there some easy way to manipulate the staged tree as part of the build? i.e. remove a file or add a symlink [16:19] this is the only library that has an issue for me while building [16:19] ssweeny, I typically install the -dev packages as build-packages and only include the runtime packages as stage-packages [16:20] ssweeny, have you tried that? [16:20] kyrofa, I did try that but the build step was looking for stuff in stage [16:20] so I assumed I was wrong [16:21] ssweeny: I haven't no. I imagine I am going to run into this on my next snappy-debug upload though, so I'm interested in what comes of this [16:21] kyrofa, so the theory of operation so to speak is the build-deps go in build-packages and runtime deps go in stage-packages. [16:22] i can try it again but I'm certain it was looking for headers in stage/include/foo [16:22] ssweeny, indeed. Not to say that having -dev in stage would hurt anything, but it bloats your snap unless you exclude them [16:22] right [16:23] ok I'll try it again. Maybe I was hitting a bug :) [16:23] thanks kyrofa [16:23] jdstrand, i'll let you know what I find [16:23] ssweeny, yeah let me know as well [16:30] do I understand correctly that it's not yet possible for an app to bind a unix socket? [16:32] the unix-listener policygroup is marked as # TODO [16:32] and I get a "denied" for this: Mar 10 16:24:48 localhost kernel: [182550.868636] audit: type=1400 audit(1457627088.221:21): apparmor="DENIED" operation="bind" profile="wifid.sideload_foreground_LSbLDVfnJSlm" pid=2988 comm="ld-linux-armhf." family="unix" sock_type="stream" protocol=0 requested_mask="bind" denied_mask="bind" addr="@776966696400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 [16:33] ysionneau: on 16.04 all of this is in flux. unix-listener is actually going away and there will be a proper interface for this [16:33] inter-app sockes within the same snap should be possible though ... [16:33] jdstrand: ok thx [16:33] ogra_: yes, but perms need to still be allowed [16:34] it is being worked through [16:34] oh, even if the socket sits in SNAP_DATA ? [16:34] ysionneau: today, use a named socket [16:34] if that is possible [16:34] since only file rules are in effect with those [16:35] ysionneau: let me check the default policy real quick [16:36] ogra_: this is an abstract socket [16:36] oh, right [16:38] neither 15.04 nor 16.04 allow binding to an abstract unix socket. 16.04 will have an interface for that [16:38] but like I said, it should work if you use a named socket [16:38] (iirc) [16:40] zyga: ok, I'm going to go pretty deep on this review and really study how things are being put together (except perhaps the xmanager bits) [16:42] jdstrand: ok thanks! [16:42] will try with a named unix socket [17:19] jdstrand: thank you [17:19] jdstrand: feel free to pull me in and ask any questions [17:20] jdstrand: I have more aa-specifc patches piled, about to be pushed out soon [17:27] jdstrand: ( https://github.com/ubuntu-core/snappy/pull/635 ) for later === chihchun_afk is now known as chihchun [17:32] ack === chihchun is now known as chihchun_afk [17:33] jdstrand: thanks [17:36] jdstrand: also FYI, for some context how I plan to plug it together, look at this list of TODOs (before it gets stale) https://github.com/zyga/snappy/blob/master/overlord/ifacestate/ifacemgr.go#L93 [17:36] ok [17:44] elopio, I just shared a google doc with you regarding the dirty build redesign [17:45] elopio, essentially a distilled problems/solutions doc [17:45] elopio, mind taking a look? [17:46] Hi folks..I am seeing apparmour issues using new ubuntu-core image [17:46] Any guidance would be of great help [17:46] We are running our app unconfined as of now [17:47] dmesg shows a lot of audit messages [17:48] http://pastebin.com/nQvfDhX5 [17:49] elopio: it's not urgent (next week) but I'd like to write a few integration tests [17:49] elopio: and I could use a quick interactive session with you [17:50] elopio: my goal is to write a test that checks that udev/apparmor support fuctions really work; this basically means setting up some files, calling a function from snappy and then checking that some stuff happened (either with more snappy functions or just with brute-force helper shell command/file poke) [17:50] elopio: when would be the best time to try this? [17:52] rajen, install snappy-debug (snappy install snappy-debug) and run sudo snappy-debug.security scanlog [17:53] rajen, wait... those messages are fine, they're just loading profiles and stuff [17:53] Here is the latest from scanlog http://pastebin.com/tAgMJX5D [17:55] rajen: is this on 16.04? [17:55] Yes 16.04 daily build [17:55] yeah, it needs to be updated [17:55]