[00:10] <asac> Chipaca: whats that?
[00:10] <asac> :)
[00:10] <asac> from the docs?
[00:11] <sergiusens> just a commit message
[00:11] <Chipaca> asac: a card, a description of a task, a branch, and a commit message
[00:11] <Chipaca> asac: i was in a maze of so many deferreds for a moment i thought i was programming twisted again
[00:11] <asac> oha
[00:11] <asac> Chipaca: was that your card :)?
[00:11] <asac> hehe
[00:11] <asac> you could have reworded it
[00:12] <asac> guess its hard to convey what that should do :)
[00:12] <Chipaca> asac: maybe :)
[00:12] <Chipaca> asac: maybe it was fun, also
[02:41] <kirkland> lool: okay, wpasupplicant has always been primitive and tricky, in my experience
[07:08] <dholbach> good morning
[08:42] <mhall119> mvo: does the PPA listed on https://developer.ubuntu.com/en/snappy/start/ need to be changed?
[08:42] <mhall119> didrocks tells me the beta PPA actually has an old version of snappy
[08:45] <mvo> mhall119: indeed, utopic and trusty are outdated, I updated them now, so that shold be fine. we may still want to use a different one when snappy gets released (i.e. the beta name sounds wrong then). asac has the final say here
[08:47] <dpm> dholbach, ^
[08:48] <dholbach> asac, lool, slangasek: ^
[08:48] <dholbach> I asked at least 5-10 times which PPA to use :)
[08:48] <dholbach> which are we going to use? :)
[08:48] <dholbach> I'm obviously happy to change it, but I'm a bit confused
[08:51] <dholbach> mvo, ^ were there any discussions about changing the ppa setup and nomenclature?
[08:57] <asac> good question
[08:57] <asac> i think we will be using a new ppa :)
[08:57] <asac> lol
[08:58] <mvo> dholbach: only asac knows that :) I think it should be staging -> beta -> tools and we use tools for the final and stable PPA, but iirc asac wnated a different ordering. I personally don't mind either way is fine as long as its documented
[08:58] <mvo> but if I would decide, that how I would do it
[09:01] <dholbach> we should just use the archive if you ask me personally :-P
[09:05] <mvo> good point, we could use the backports archive
[09:07] <JamesTait> Good morning all; happy Kindergarten Day! :-D
[09:10] <mvo> kickinz1: whats a good way to test docker? your tdocker snap?
[09:11] <kickinz1> mvo: For now I would say either direct command line or tdocker, yes. I need to finish owncloud snap package.
[09:14] <mvo> kickinz1: where is the docker snap? I think I need to add some caps for the seccomp stuff or make it unrestricted there (thats probably the best option for now until jdstrand is around)
[09:15] <kickinz1> mvo: launchpad.net/~snappy-dev/snappy-hub/docker/
[09:16] <mvo> ta
[09:24] <mvo> kickinz1, jdstrand: please pardon if this diff is stupid, it seems with seccomp enable I need to do at least http://paste.ubuntu.com/10860613/ in the docker-client or it won't even talk to docker (i.e. the docker command will just hang)
[09:30] <kickinz1> mvo: is it with new seccomp code in the image? (it was working yesterday)
[09:31] <mvo> kickinz1: it landed during the night
[09:31] <kickinz1> mvo: ok, I'm downloading it right now.
[09:34] <mvo> kickinz1: you will need to apply the pasted patch  to make it work at all, dmesg will indicate if something goes wrong, the kernel message starts with "audit:"
[09:36] <kickinz1> mvo thanks
[09:38] <mvo> Chipaca: hm, hm, this should not be possible, right? http://paste.ubuntu.com/10860659/ - note the two pastebinit packages I managed to install first I installed it via the store and then sideloaded it and that worked :/
[09:39] <Chipaca> mvo: sideload always works
[09:40] <Chipaca> oh
[09:40] <Chipaca> oooh
[09:40] <Chipaca> ouch
[09:40] <Chipaca> mvo: i thought it was going to be about versions, not about namespaces
[09:40] <Chipaca> ouch
[09:40] <Chipaca> mvo: i'll look into it as soon as i get this branch up
[09:41] <mvo> Chipaca: thanks ,you rock!
[09:41] <mvo> much much appreciated
[09:41]  * mvo dives back into seccomp land
[09:42] <Chipaca> mvo: before you're in too deep
[09:42] <Chipaca> mvo: sideload install of an already installed package is ok, yes?
[09:42] <Chipaca> that is, we don't want to force devs to bump revno or uninstall to test their packages
[09:42] <Chipaca> ?
[09:42] <beuno> FWIW, I sort of think that what distinguishes sideloading from not is whether it's signed by the store
[09:43] <mvo> Chipaca: oh, sideload again a already sideloaded one? yeah, I guess, but we will probably run into the textfile-busy problem we had earlier when we allowed reinstall. its a problem worth fixing and maybe its ok for sideload
[09:44] <Chipaca> mvo: textfile busy should be sorted now that we stop things properly, mehtinks
[09:46] <mvo> yay
[09:46] <mvo> then go for it
[09:46] <mvo> excellent news
[09:47] <mhall119> dholbach: so are we waiting to hear from asac about which PPA to use in our docs?
[09:47] <asac> mhall119: we are talking :)
[09:47] <asac> about that
[09:47] <asac> mhall119: if you want to participate join the call on my calendar right now
[09:47] <mhall119> ok, cool, I'll leave that in your hands then
[09:48] <mhall119> asac: as long as I can tell didrocks it's being done, I'm happy :)
[09:50] <asac> mhall119: why is didrocks so worried?
[09:50] <asac> is he depending on us?
[09:50] <mhall119> asac: because he saw that it was wrong and he's sitting across the table from me
[09:51] <mhall119> asac: he's working on a prototype with it this week I think
[09:51] <mhall119> I don't think he's blocked, just noticed an error in our docs
[10:06] <asac> mhall119: is he willing to join this channel :)?
[10:12] <didrocks> hey
[10:13] <robert_ancell> asac, oh, the PPA was via me. I was reading the docs and assumed it was wrong. You guys were all asleep when I was asking from .nz :)
[10:14] <didrocks> asac: so not blocked on that, but we just posted an email to snappy-devel ML with a simple example (even if we have way more questions/wonderings), so as soon as you get some time to look at it… that would be appreciated!
[10:15] <asac> hey didrocks :)
[10:15] <asac> welcome to the snappy world
[10:17]  * beuno hands didrocks the standard-issue goggles
[10:17] <didrocks> :)
[10:27] <Chipaca> mvo: fix for sideload & namespaces messing things up: https://code.launchpad.net/~chipaca/snappy/check-namespaces-on-sideload/+merge/256904
[10:44] <asac> jodh: how is self test going?
[10:44] <jodh> asac: we're now blocked on a store issue.
[10:44] <asac> beuno: ^
[10:44] <asac> jodh: whats the issue in one line?
[10:45] <jodh> asac: installing a framework breaks 'snappy search'
[10:46] <asac> thats a store problem>
[10:46] <asac> hmm
[10:46] <asac> nessita: ^^
[10:46] <asac> JamesTait: ^
[10:46] <jodh> asac: Chipaca has raised a MP which is now approved, but needs to be merged + included in an image.
[10:46] <beuno> asac, mvo and Chipaca know about it, not a store issue, really
[10:46] <asac> jodh: an MP against the store?
[10:46] <beuno> :)
[10:46] <asac> jodh: ok, please be more precise :)
[10:47] <asac> so its a snappy bug
[10:47] <asac> Chipaca: mvo: i guess you are on it?
[10:47] <jodh> asac: it's a store issue or a snappy issue :)
[10:47] <Chipaca> it's a bug in the system, which includes the client and the store. We've decided to fix it on the client.
[10:48] <Chipaca> it keeps the parts consistent
[10:48] <asac> ok
[10:48] <Chipaca> that is: the store is self-consistent on this matter, the client is not
[10:48] <Chipaca> so it made sense to fix it in the client
[10:48] <asac> yeah
[10:48] <Chipaca> even if we could have also fixed it from the store
[10:48]  * JamesTait grabs popcorn
[10:48] <asac> makes sense
[10:48] <asac> thanks
[10:49] <Chipaca> JamesTait: sorry to disappoint :)
[10:50]  * ogra_ steals JamesTait's popcorn bucket
[10:50] <JamesTait> Not at all, Chipaca, happy to help if it's needed, happy to stand aside otherwise.
[10:50] <Chipaca> JamesTait: i meant wrt popcorn :)
[10:51]  * JamesTait throws unpopped kernels at ogra_ and Chipaca.
[10:51]  * JamesTait whistles innocently, points at beuno.
[10:53]  * Chipaca feels he's already thrown enough mock abuse at beuno for a few more minutes still
[10:55] <davmor2> Chipaca: you mean there is a limit to the mock abuse you can throw at beuno, why am I the last to learn of this?
[10:56] <Chipaca> davmor2: that depends on the acerbity of your abuse
[10:56] <Chipaca> davmor2: with me having slept so little, i don't trust myself
[10:56] <davmor2> Chipaca: hahahaha
[10:56] <Chipaca> davmor2: also, beuno is within range for a lot more weapons than normally
[10:57] <Chipaca> I don't think he's within the record sniper 'confirmed kill' range, but it's close
[11:16] <robert_ancell> Trying to build a lightdm snap here. First blocker - LightDM needs PAM configuration to work. This requires installing files into /etc/pam.d. How do we do this? Does ubuntu-core need some sort of hook to pull PAM configuration from frameworks that require it?
[11:36] <asac> didrocks: you have to subscribe using your @canonical.com
[11:36] <asac> the other will be unsubscribed
[11:42] <ogra_> carzy annoyances :P
[11:43] <dholbach> davidcalle, dpm: I'll look into amending the snappy internal docs for use as guides next
[11:43] <dholbach> davidcalle, dpm: feel free to take any of the other work items
[11:43] <davidcalle> dholbach, dpm, I'm on the architecure page + diagram
[11:44] <dholbach> davidcalle, excellent - are you going to import any content for that?
[11:44] <didrocks> asac: hum, ok :)
[11:44] <davidcalle> dholbach, from the slides?
[11:44] <dholbach> ok cool
[11:45] <dholbach> thanks a lot
[11:45] <didrocks> asac: done
[11:45] <ogra_> didrocks, i was pondering to set up a petition to get the (10 years well working) old scheme back for MLs :)
[11:45]  * ogra_ is seriously annoyed by getting half his mails back because he forgets to swithc to the other account
[11:49] <asac> mterry: will you be in standup today?
[11:49] <dpm> davidcalle, I was going to pick the WI of modifying the diagram to add the enablement bit. Are you planning on taking that one too? If so, I'll leave it up to you :)
[11:49] <davidcalle> dpm, I've just finished :)
[11:49] <dpm> \o/
[11:57]  * dholbach relocates to the office, brb
[11:58] <davidcalle> dpm, what do you think? (to me, it works well) https://developer.ubuntu.com/en/snappy/guides/architecture/
[12:02] <dpm> davidcalle, good work. Seems like the "How does it work" row is both on the landing page and the architecture one. Would it not make sense to have it only in one place?
[12:03] <davidcalle> dpm, right, removing it from architecture
[12:05] <sergiusens> dpm: davidcalle you can have an app directly on top of ubuntu core too
[12:05] <dpm> davidcalle, I think after release it might be work redrawing the  "Stack examples" diagrams so that they are more inline with the rest of the site, and have a <h2> section for each one of them
[12:07] <dpm> sergiusens, davidcalle, then perhaps we can say "an optional layer of frameworks" in the text?
[12:25] <dholbach> davidcalle, dpm, I'll drop the snappy internals for now
[12:25] <dholbach> asac said it'd be good to look at the image channels and stuff first
[12:25] <dpm> dholbach, ok
[12:25] <dholbach> and the ./start page
[12:26] <dholbach> I'll look into writing the content for the channels page
[12:26] <dholbach> and then we can take it from there
[12:26] <dpm> dholbach, what's there to do in the start page?
[12:26] <dholbach> ?
[12:26] <dholbach> ah ok
[12:26] <dholbach> well, the start page contains all the links to all kinds of images
[12:26] <dholbach> there will have to be links or at least mentions of other releases/channels
[12:28] <asac> slangasek: would be great if we could get the first prebuilt images done early today so davidcalle and dholbach can put together our nice page to find the right bits and pieces
[12:31] <dpm> dholbach, ah, got it now, I wasn't thinking to it in relationship with the image channel links
[12:34] <dpm> dholbach, if you need the diagram, here's where I created it back in the day for the devices page: https://docs.google.com/drawings/d/1CxoxNsWGA3r5IS9ZavfSR_QbhlAKE2D9KaCtvL-zM88/edit
[12:36] <dholbach> thanks - that's greta
[12:36] <dholbach> great
[12:38] <mterry> asac, I can make sure to be, yeah
[12:39] <asac> mterry: great. woudl be nice to get an update and coordinate what and how to bring stuff togethher for release
[12:39] <asac> thanks
[12:42] <jdstrand> mvo: re docker-- yeah, that's fine, though I'm starting to feel like network-service isn't a useful group-- docker client is not a server yet it needs bind
[12:44] <asac> jdstrand: mvo: apps can depend on multiple frameworks right now, correct?
[12:44] <jdstrand> they should be allowed to, yes
[12:45] <mvo> yes
[13:16] <dholbach> davidcalle, do you know why there are no margins on https://developer.ubuntu.com/en/snappy/guides/channels/?
[13:17]  * dholbach surely broke something :-P
[14:02] <dholbach> do we have something like -proposed in terms of image creation?
[14:02] <dholbach> or is that just 'edge'?
[14:02] <dholbach> slangasek, ^
[14:02] <slangasek> dholbach: edge, was previously called -proposed
[14:03] <dholbach> thanks
[14:04] <sergiusens> slangasek: can you look at my man generation mp?
[14:05] <slangasek> sergiusens: otp, will be able to later
[14:05] <sergiusens> stgraber: btw, if I'm on trusty, is there a ppa for lxc where the download template would have vivid images?
[14:05] <sergiusens> ty steve
[14:06] <asac> sergiusens: what still needs landing before we can featuure freeze?
[14:06] <asac> mvo: ?
[14:06] <sergiusens> asac: I need some u-d-f stuff; just finished the oem bug work and now moving to autopilot autoreboot
[14:06] <sergiusens> asac: the security stuff is still in the works
[14:06] <stgraber> sergiusens: ppa:ubuntu-lxc/stable should get you a recent enough lxc for that
[14:06] <sergiusens> asac: blocking sideloaded updates
[14:06] <sergiusens> stgraber: thanks!
[14:07] <sergiusens> asac: and some fixes from Chipaca
[14:09] <asac> sergiusens: ok you think we can get those in before EOD and still have a good image to start freeze?
[14:10] <sergiusens> asac: well, the security stuff doesn't depend on the team
[14:10] <asac> dholbach: so i assume those stack pics will not stay on the channels guides?
[14:11] <asac> i think i can use them in the appliance guide ... and maybe we can improve the thing on the architecture inspired by these
[14:12] <mvo> asac: we are mostly good, two unapproved branches left, not critical IMO, the launcher needs some further work and discussion with the security team, some real concerns here. worst case is that we need to disable the hardware: assign: feature if there is no solution found
[14:12] <dholbach> asac, sure... it's not done yet
[14:12] <dholbach> asac, once it is, I'll let you know :)
[14:13] <mvo> asac: we also don't hvae a image with the latest ubuntu-snappy, I don't know why, there should be at least one since 418, I wonder if its because of arm64 :/
[14:15] <asac> slangasek: ^^
[14:16] <dholbach> dpm, davidcalle, can you help me with the styling of https://developer.ubuntu.com/en/snappy/guides/channels/?
[14:16] <asac> mvo: 418? i dont have that high numbers
[14:16] <asac> i am on 18 or something witjh the new channel names
[14:16] <asac> mvo: maybe you are leeching on the old channels?
[14:17] <dpm> dholbach, on it
[14:17]  * dholbach hugs dpm
[14:17] <asac> jdstrand: can you please think hard how we can make it so that we dont need to disable the hwassign feature?
[14:17] <mvo> asac: this is the amd64 image number
[14:17] <jdstrand> I'll invite tyhicks to the standup, he did the review
[14:18] <asac> i really would prefer a solution than a discussion though.
[14:18] <mvo> jdstrand: I'm happy to fix it, I just need some input what the best aproach is, maybe we need to brainstorm it from what we need instead of what we have right now
[14:20] <dholbach> dpm, nice work - how did you do it?
[14:20] <dholbach> dpm, davidcalle: does the text generally make sense to you? :)
[14:20] <dpm> dholbach, for Raw HTML, you need to enclose the whole page in <div class="row"></div>
[14:20] <dholbach> ohoh ok!
[14:21] <dpm> dholbach, and then within that row, you can choose how many columns with <div class="eight-col"></div>
[14:21] <dholbach> gotcha
[14:21] <tyhicks> I'll attend the standup
[14:21] <tyhicks> unfortunately, I don't have a solution atm
[14:21] <jdstrand> mvo: are you planning another ubuntu-snappy upload? I'd like to drop the reference to apparmor-easyprof-ubuntu-snappy in debian/control. that is gone. easiest is to replace it with ubuntu-core-security-apparmor
[14:22] <jdstrand> (note, nothing is broken because ubuntu-core-security-apparmor Provides apparmor-easyprof-ubuntu-snappy)
[14:22] <mvo> jdstrand: I think I did that already, let me check
[14:23] <mvo> jdstrand: yep, trunk has no easyprof string anymore AFAICS
[14:23] <jdstrand> ok, thanks
[14:26] <dholbach> mvo, asac: is http://paste.ubuntu.com/10861645/ what we want documented for the ppa?
[14:26] <dholbach> just to be sure :)
[14:51] <asac> dholbach: so all tools will be available for trusty,vivid
[14:51] <asac> 15.04/stable = {trusty,utopic,vivid}/tools
[14:51] <asac> as an example
[14:52] <dholbach> asac, ok - what is "tools" in this nomenclature - what kind of stability can be expected there - how often is it updated?
[14:54] <dholbach> asac, is the note on the right hand side of the webdm page (https://developer.ubuntu.com/en/snappy/guides/webdm/) what you were looking for?
[14:59] <dholbach> dpm, davidcalle: do you think we should try to separate the links on https://developer.ubuntu.com/en/snappy/participate/? ie, "articles for hardware enablement", "articles on snappyfication" or "articles about snappy in general"
[15:00] <slangasek> mvo: which channel are you looking for the import to happen on?
[15:02] <mvo> slangasek: devel-proposed, is that the wrong one?
[15:03] <slangasek> I don't know
[15:03] <slangasek> I'm asking so I can check :)
[15:05] <slangasek> mvo: ubuntu-core/15.04/edge/, last import was Apr 21 9:41 - same as devel-proposed.  So it's not that
[15:33] <sergiusens> mvo: I updated the auto reboot branch
[15:36] <dholbach> thanks sergiusens!
[16:43] <jdstrand> tyhicks: fyi, r35 for ubuntu-core-security
[16:43] <jdstrand> tyhicks: (makes the network-* changes we discussed)
[16:58] <tyhicks> jdstrand: sorry for the delay - I'm just thinking through that change a little more
[16:59] <tyhicks> jdstrand: I thought that you weren't going to add all the permissions to network-client until the socket params were filtered
[17:00] <tyhicks> mvo: fyi - I verified that not doing setgroups() is fine in this case
[17:13] <jdstrand> tyhicks: heh, obviously I thought they'd be the same except for socketpair
[17:14] <jdstrand> tyhicks: that said, if you think there are things that should be in one and not the other, that's fine with me. my understanding coming out of there was that only socketpair is actually server related
[17:14] <jdstrand> err
[17:14] <jdstrand> server only
[17:15] <tyhicks> jdstrand: what I was trying to say was that an app doing AF_UNIX communication may need many of the things that are in network-service
[17:15] <jdstrand> right, which is why I added them to client
[17:15] <tyhicks> ok
[17:15] <tyhicks> I thought that was going to happen after the arg filtering
[17:15] <jdstrand> because this separation is meant for inet/inet6
[17:16] <tyhicks> I don't think it makes a big difference though since we plan to do the arg filtering
[17:16] <tyhicks> right
[17:16] <tyhicks> really, there is AF_UNIX and AF_INET/AF_INET6
[17:16] <tyhicks> it is tough to split on client and server since those terms mean different things between those 3 domains
[17:17] <jdstrand> tyhicks: the are essentially the same now because I don't want people to ask for network-service now when they don't need it. that way people can add in network-service once we support arg filtering
[17:17] <tyhicks> ok
[17:17] <jdstrand> re tough split> exactly
[17:17] <tyhicks> wfm
[17:17] <jdstrand> I realize there is no practical difference now
[17:17] <tyhicks> I'm reviewing the seccomp filter now
[17:17] <jdstrand> this is for establishing the groups for the future
[17:17]  * tyhicks nods
[17:19] <jdstrand> tyhicks: re review, thanks
[17:29] <mvo> thanks tyhicks
[17:30] <mvo> pitti: is there a API to figure from a libudev device to get if its a block or char device? I'm overlooking something silly probably
[17:30] <pitti> mvo: no, this is curiously hard to determine
[17:31] <pitti> mvo: that's why in the PoC I was checking for "/block/" in the device path, otherwise it's a char
[17:33] <mvo> pitti: ok, thats all I need to know, thanks
[17:33] <pitti> mvo: that should be pretty safe
[17:42] <jdstrand> tyhicks, mvo: fyi, http://paste.ubuntu.com/10862547/
[17:42] <jdstrand> updating the packaging now and will request an MP
[17:43] <jdstrand> I think I am going to be more lenient on the uevent rule
[17:43] <jdstrand> /sys/devices/**/uevent r,
[17:43] <jdstrand> we can finetune that later if needed
[17:47] <tyhicks> jdstrand: wow - nice profile
[17:47] <tyhicks> (minus having to include cap_sys_admin)
[17:47] <jdstrand> yeah
[17:48] <jdstrand> it is what it is
[17:48] <tyhicks> jdstrand: oh, were you going to deny transitioning to unconfined?
[17:48] <jdstrand> Chipaca: that comment was for you ^
[17:48] <jdstrand> tyhicks: oh yes, thanks for reminding me
[17:48] <Chipaca> jdstrand: which comment?
[17:48] <jdstrand> Chipaca: 'it is what it is'
[17:48] <jdstrand> Chipaca: I know how much you like that phrase ;)
[17:49] <jdstrand> </lame joke>
[17:49] <Chipaca> in my defence it was a long week and i was somewhat sleep deprived
[17:49] <jdstrand> I liked what you had to say about it
[17:50] <jdstrand> :)
[17:54]  * Chipaca hopes the memories will come back someday
[17:54]  * Chipaca also hopes he wasn't rude
[17:55] <mvo> stgraber, tyhicks: hrm, hrm, so after some refactoring it seems like devices.allow is too clever and just having the FD is not good enough, it will deny access, from looking at the source it appears its checking if the task has CAP__SYS_ADIM so the open fd and then do the rest with thta seems to not work (which is really disappointing)
[17:55] <jdstrand> Chipaca: it was something along the lines of, "Have you ever noticed that when someone says 'it is what it is' it usually means it is sh!+"
[17:56] <jdstrand> hehe
[17:56] <jdstrand> awesome
[17:56] <stgraber> mvo: gah, I hate it when checks are done on write rather than open...
[17:58] <jdstrand> jjohansen: heh, can you look at this: http://paste.ubuntu.com/10862602/
[17:58] <Chipaca> jdstrand: well, i wasn't wrong :)
[17:58] <jdstrand> jjohansen: s/heh/hey/
[17:58] <jdstrand> Chipaca: you weren't! :)
[17:58] <jjohansen> jdstrand: sure
[17:58] <jdstrand> jjohansen: clearly, that says that I don't want to allow transitioning to unconfined
[17:59] <jdstrand> jjohansen: I was thinking I wanted to say "not to unconfined and not to a profile that starts with '/'"
[18:00] <jdstrand> jjohansen: but I wasn't sure how to express the alternation
[18:00] <jjohansen> jdstrand: yeah that should do it, by why that instead of using a deny?
[18:00] <jdstrand> jjohansen: oh heh, yes, that would be considerably cleaner, haha
[18:00] <jdstrand> jjohansen: thanks!
[18:00]  * jdstrand grabs brown bag
[18:00] <jjohansen> deny change_profile -> {unconfined,/**},
[18:00] <jjohansen> change_profile -> **,
[18:01] <jjohansen> jdstrand: so this is one area of the language that could really use some improvements
[18:01] <jdstrand> yeah
[18:01] <jjohansen> there are just some things that are really hard to express
[18:01] <jdstrand> in this case, the deny rules do a great job
[18:02] <jdstrand> jjohansen: change_profile -> **, why the '**'?
[18:02] <jjohansen> yeah but if you start doing stuff like that in the deny rule ...
[18:02] <jjohansen> * will stop at /  just as with file paths
[18:02] <mvo> stgraber: yeah, unless there are more smart ideas I think I can not make the critical section smaller
[18:02] <jjohansen> you may not care as they shouldn't be in the names you are allowing
[18:03] <jdstrand> jjohansen: so, 'foo' ok, but 'foo/bar', no
[18:03] <jjohansen> right
[18:03] <jdstrand> that makes sense
[18:03] <jdstrand> ok, thanks again
[18:03] <jdstrand> tyhicks: did you see mvo's last comment? ^
[18:03] <tyhicks> oh, no
[18:04] <jdstrand> what if we dropped all caps except sys_admin until after the cgroups?
[18:04] <mvo> jdstrand: let me try that
[18:04] <mvo> well, its terrible but better than full root
[18:05] <mvo> (well, maybe not, I need to check what is allowed with that)
[18:05] <tyhicks> dropping all except sys_admin doesn't gain us much
[18:06] <tyhicks> let me look back at the launcher code to see if I have any other ideas
[18:09] <jdstrand> jjohansen: hrm, seems we have a parser bug
[18:10] <jjohansen> jdstrand: ?
[18:10] <jdstrand> jjohansen: all of these give a parser error:
[18:10] <jdstrand> #    deny change_profile -> {unconfined,/**},
[18:10] <jdstrand> #    deny change_profile -> unconfined,
[18:10] <jdstrand> #    deny change_profile -> /**,
[18:10] <jdstrand> AppArmor parser error for /home/ubuntu/usr.bin.ubuntu-core-launcher in /home/ubuntu/usr.bin.ubuntu-core-launcher at line 32: syntax error, unexpected TOK_CHANGE_PROFILE, expecting TOK_ID or TOK_MODE or TOK_SET_VAR
[18:12] <jjohansen> jdstrand: indeed, and ouch
[18:12] <jdstrand> jjohansen: my previous paste works
[18:12] <jjohansen> I'll get right on it
[18:12] <jdstrand> jjohansen: so, I guess I am back to my previous question on the alternation
[18:12] <jjohansen> right, its complaining about deny with change_profile
[18:12]  * jdstrand nods
[18:12] <jdstrand> jjohansen: I don't think it is worth an emergency upload. we can SRU the fix
[18:13] <jdstrand> jjohansen: I'll file a bug and reference it in the profile
[18:13] <jjohansen> sure not worth an emergency upload but something to get done
[18:13] <jdstrand> I imagine it is a pretty easy fix
[18:13] <jjohansen> jdstrand: give me a sec, to paste you it
[18:14] <tyhicks> mvo: bummer... I don't see another obvious idea
[18:15] <jjohansen> jdstrand: http://paste.ubuntu.com/10862679/
[18:16] <tyhicks> mvo: we could temporarily drop, do the udev stuff, regain, write the devices lists, then permanently drop
[18:16] <tyhicks> mvo: but I don't know that it gains us much
[18:16] <tyhicks> mvo: I'll look at the udev code to see if it is a concern
[18:18] <jdstrand> jjohansen: ok, that was what I was thinking. thanks
[18:18] <jdstrand> jjohansen: fyi, https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1446794
[18:18] <jjohansen> thanks
[18:26] <mvo> tyhicks: well, drop and regain is not that helpful (from my limited understanding about the security I have). I am playing with libcap right now, but again limited success, I will get the kernel source next to see what its actually checking
[18:26] <mvo> "it" being the devices.allow write of course
[18:26] <tyhicks> mvo: ah, I'll do that "it"
[18:34] <mterry> If I want to upload a package to the Snappy store, but like on behalf of a team (for example, ~mir-team), how do I do that?  I'm not sure how to not upload just as me
[18:37] <tyhicks> mvo: ah, just noticed one more thing - the fclose() ret val needs to be checked in write_string_to_file() since there's not an explicit fflush()
[18:41] <tyhicks> mvo: when writing to the device cgroup files, devcgroup_update_access() does the real work and it immediately returns an error if 'current' does not have CAP_SYS_ADMIN: http://lxr.free-electrons.com/source/security/device_cgroup.c#L603
[18:41] <tyhicks> mvo: there's no way around it :/
[18:57] <mvo> tyhicks: yeah, I found that too, thanks! I have http://bazaar.launchpad.net/~mvo/ubuntu-core-launcher/drop-root-early-use-caps/revision/45 that drops root earlier, the code is not clean (enough) yet but my brain is a bit fried right now not sure if this is worth it or not
[19:00] <tyhicks> looking now
[19:00] <jdstrand> mvo: fyi, I'm just about to do a MP for the apparmor profile for ucl
[19:00] <jdstrand> (ubuntu-core-launcher)
[19:02] <mvo> jdstrand: nice, does it work with exotic apps like docker?
[19:03] <mvo> (I assume it does :) still curious)
[19:03] <jdstrand> I am trying docker right now
[19:07] <jdstrand> I missed one rule
[19:07]  * jdstrand is testing now
[19:11] <jdstrand> docker itself has an issue:
[19:11] <jdstrand> Apr 21 19:10:35 localhost kernel: [22039.617003] audit: type=1400 audit(1429643435.305:104): apparmor="DENIED" operation="file_mprotect" profile="docker_docker-daemon_1.6.0.001" name="/bin/bash" pid=1886 comm="docker.start" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[19:13] <tyhicks> mvo: I think that patch does help
[19:14]  * jdstrand fixes docker
[19:14] <tyhicks> mvo: I haven't went through all of the cap_*() calls closely but I understand what you're doing
[19:15] <mvo> tyhicks: ok, I will take a break and either do the cleanup now or tomorrow morning, plus new tests, the old approach is no longer working but I have a plan for new tests
[19:16] <mvo> tyhicks: and THANKS for your help with this!
[19:16] <mvo> much appreciate the feedback I got
[19:16] <tyhicks> mvo: thanks for the quick turnaround on everything! :)
[19:16] <jdstrand> mvo: https://code.launchpad.net/~jdstrand/ubuntu-core-launcher/ubuntu-core-launcher.aa-profile/+merge/256992
[19:16] <jdstrand> mvo: if you are using libcap, the profile will need to be updated
[19:16] <tyhicks> mvo: I'll go back through the list and verify that everything has been done and, if necessary, propose some changes for you
[19:17] <tyhicks> s/everything/everything important/
[19:17] <jdstrand> mvo: (it should be easy to see what needs to be done, but I/tyhicks can also help)
[19:17] <jdstrand> ah meh, conflict
[19:17]  * jdstrand resolves
[19:17] <jdstrand> these branches are moving to fast :)
[19:18] <jdstrand> (it's just the changelog)
[19:22] <jdstrand> tyhicks: here is the final profile: https://code.launchpad.net/~jdstrand/ubuntu-core-launcher/ubuntu-core-launcher.aa-profile/+merge/256992
[19:23] <jdstrand> mvo: ok, that ^ is ready to pull in (obviously update as necessary for your changes)
[19:25] <tyhicks> jdstrand: looks good
[19:31]  * jdstrand uploads docker with the small profile change
[19:32] <jdstrand> kickinz1: fyi ^
[19:32] <jdstrand> kickinz1: committed to the branch
[19:33] <jdstrand> kickinz1: can you delete ./package-dir/meta/docker-daemon.*priv now that they are no longer needed?
[19:50] <mvo> jdstrand: thanks, uploaded! hints what the libcap branch needs for apparmor would be great (ideally by mail). I will check in my morning (in +8h) and continue on the capability branch
[20:02] <kickinz1> jdstrand: I'll do
[20:04] <asac> lool: still around?
[20:04] <asac> lool: do you have the code for the demo that displays stuff on the mini LED screen still?
[20:09] <jdstrand> kickinz1: thanks!
[20:19] <jdstrand> tyhicks: fyi, r37 of ubuntu-core-security
[20:19] <jdstrand> (added capget)
[20:22] <kickinz1> jdstrand: done, but I will try uploading when owncloud package is somehow working, caus I think it will need some apparmor adjustment (bind mounts).
[20:22] <tyhicks> jdstrand: ack - are you ok with me explicitly denying umount and umount2?
[20:23] <jdstrand> tyhicks: yes
[20:23] <tyhicks> pushed
[20:24] <jdstrand> tyhicks: are you ok with my doing the same in apparmor? :)
[20:24] <tyhicks> jdstrand: yes :)
[20:24] <tyhicks> jdstrand: don't forget about remount in apparmor (it is a separate rule)
[20:27] <jdstrand> right, done
[20:27] <jdstrand> and pushed
[20:32] <jdstrand> ubuntu-core-security 15.04.6 pushed to the image ppa
[20:32] <jdstrand> kickinz1: you are going to need that ^ for docker to work correctly
[20:35] <kickinz1> jdstrand: ok, thanks.
[20:35] <asac> jdstrand: you know what is left still?
[20:35] <asac> for mvo :
[20:36] <jdstrand> asac: a few finish touches on the launcher
[20:36] <jdstrand> finishing*
[20:36] <asac> hmm
[20:36] <asac> what needs doing?
[20:36] <jdstrand> the last bits from the security review
[20:36] <jdstrand> aiui
[20:37] <jdstrand> there was a snag with passing fds (it didn't work), so an alternate implementation that wasn't as comprehensive is being done
[20:37] <jdstrand> the apparmor profile bits are in the image ppa
[20:37] <asac> ok, what hints is he waiting for>
[20:37] <asac> ?
[20:37] <jdstrand> (ie, ubuntu-core-launcher runs under the profile)
[20:37] <jdstrand> none
[20:37] <asac> 21:50 < mvo> jdstrand: thanks, uploaded! hints what the libcap branch needs for apparmor would be great (ideally by mail). I will check in my morning (in +8h) and continue on the capability branch
[20:38] <jdstrand> oh, that
[20:38] <jdstrand> I sent that to him already
[20:38] <asac> k
[20:38] <jdstrand> it is just how to update the aforementioned profile for if he uses libcap
[20:39] <asac> sergiusens: so on my image sshd is not started by default
[20:39] <asac> sergiusens: ignore... let me recreate
[20:39] <asac> not 100% sure i --enable-ssh
[20:40] <kickinz1> jdstrand: so I need a new image? Which revision ?
[20:41] <sergiusens> asac: if you wait for the publisher to finish maybe try the latest u-d-f? But it does need a new image build as snappy list is broken
[20:41] <jdstrand> kickinz1: it isn't on the image yet. you can grab a new image, then do: sudo mount -o remount,rw / ; sudo dpkg -i /tmp/*.deb ; sudo mount -o remount,ro /
[20:42] <jdstrand> kickinz1: pull the 3 ubuntu-core-security packages from https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages
[20:42] <jdstrand> kickinz1: note, I am getting non-apparmor/seccomp error when doing 'docker pull ubuntu:trusty'
[20:42] <jdstrand> kickinz1: I was going to follow what is in framework-policy/apparmor/policygroups/client, but the docker repo seems broken
[20:44] <jdstrand> sudo docker pull ubuntu:trusty
[20:44] <jdstrand> ...
[20:44] <asac> sergiusens: from trusty
[20:44] <jdstrand> Error pulling image (trusty) from ubuntu, Untar exit status 1 operation not permitted Untar exit status 1 operation not permitted
[20:44] <jdstrand> maybe it isn't their repo
[20:44] <asac> sergiusens: ppa?
[20:44] <jdstrand> but no denials of any kind
[20:45] <jdstrand> kickinz1: anyway, I have to step away for a little while. I'll be back later
[20:45] <asac> sergiusens: getting 0.20snappy7-0ubuntu1 and will redo the flash
[20:45] <kickinz1> jdstrand, trying locally (out of snappy) to check (pull ubuntu:trusty)
[20:46] <asac> sergiusens: which channel?
[20:46] <asac> sergiusens: 15.04 edge?
[20:46]  * asac thinks we still work on rolling/edge until we cut it
[20:47] <asac> sergiusens: this is what i am now dd'ing https://pastebin.canonical.com/130045/
[20:47] <asac> or open paste: http://paste.ubuntu.com/10863294/
[20:47] <kickinz1> jdstrand: ubuntu-core-{launcher,meta,security}?
[20:48] <kickinz1> jdstrand: ok, sorry
[20:54] <asac> sergiusens: still have invalid package on system :/
[20:55] <asac> sergiusens: system-image-cli -i
[20:55] <asac> current build number: 18
[20:55] <asac> device name: generic_armhf
[20:55] <asac> channel: ubuntu-core/rolling/edge
[20:55] <asac> last update: 2015-04-21 18:27:44
[20:55] <asac> version version: 18
[20:55] <asac> version ubuntu: 20150421.A
[20:55] <asac> version raw-device: 20150421.A
[20:56] <asac> sergiusens: this doesnt help me much
[20:56] <asac> sergiusens: yuou say w eneed a new image build>?
[20:56] <asac> do we have the fix landed?
[20:58] <asac> slangasek: https://launchpad.net/~snappy-dev/+archive/ubuntu/image this ppa is in theory in image?
[20:59] <slangasek> in practice, not just in theory
[21:00] <slangasek> the next scheduled image livecd-rootfs build is in 56 minutes; after which we need to again mangle for importing
[21:00] <asac> ok copied the snappy binary :)
[21:00] <asac> it works
[21:00] <asac> i love go :P
[21:01] <asac> ok the launcher seems to be old style
[21:06] <asac> jdstrand: hello-world.env
[21:06] <asac> Bad system call
[21:06] <asac> thats the problem?
[21:06]  * asac reboots
[21:07] <sergiusens> asac: yes; you need snappy trunk
[21:07] <sergiusens> asac: and your u-d-f command was good
[21:07] <sergiusens> slangasek: asac  can we trigger a build sooner?
[21:08] <asac> i would love to see whats in
[21:08] <asac> right now i feel its broken
[21:08] <asac> but maybe my copying didnt do the good thing
[21:08] <asac> slangasek: sergiusens: ok if we kick an image?
[21:09] <asac> given that we have to mangle once anyway :)
[21:09] <asac> it would help us getting answers sooner
[21:09] <slangasek> yes
[21:09] <slangasek> triggered
[21:09] <asac> gratias
[21:10] <asac> hmm. guess i need the new -security package
[21:10] <asac> to get the syscall problem above eliminated
[21:11] <asac> ok, i am sure all is fine its relly just installing that swecuerity stuff
[21:31] <kickinz1> jdstrand: on r404, installed debs + install docker, seems to work. r419: no way, same error as you.
[21:31] <kickinz1> jdstrand: put docker in debug mode, not much more info...
[21:33] <kickinz1> jdstrand: seems related to auplink. Does auplink need some seccomp profile?
[21:42] <asac> kickinz1: whats the error you see?
[21:47] <kickinz1> asac; same as jdstrand: FATA[0016] Error pulling image (latest) from cirros, Untar exit status 1 operation not permitted
[21:48] <kickinz1> asac: I put docker on debug mode, same message, I'm trying to strace, no better info...
[21:48] <kickinz1> asac: last traces from strace:
[21:48] <kickinz1> asac: http://paste.ubuntu.com/10863526/
[21:50] <kickinz1> asac: on, r404, all clear...
[21:53] <asac> kickinz1: i am on r22 :/
[21:53] <asac> kickinz1: how do you produce the image?
[21:54] <kickinz1> I made a little script.
[21:54] <kickinz1> asac; r22 on amd64?
[21:54] <kickinz1> asac: r22 -> bbb?
[21:55] <asac> no on amd64
[21:55] <asac> kickinz1: how do you produce the image?
[21:55] <asac> or is it an upgraded one?
[21:55] <kickinz1> asac: generated one: http://paste.ubuntu.com/10863556/
[21:56] <sergiusens> kickinz1: heh, keyboard layout is killed on the latest images
[21:56] <sergiusens> kickinz1: are you using ppa:snappy-dev/tools?
[21:57] <kickinz1> sergiusens, for building?
[21:57] <sergiusens> kickinz1: yeah
[21:57] <asac> slangasek: ready for a manual mangling?
[21:57] <kickinz1> sergiusens, no I'm using snappy bin from images (I may not use the r419 though)
[21:57]  * asac hopes new image is ready now
[21:57] <sergiusens> kickinz1: sorry, I meant u-d-f
[21:58] <slangasek> asac: yes, doing
[21:58] <asac> kickinz1: this is revision for snappy tool?
[21:58]  * asac confused... i cannot install anything with that high numbers after our channel redo
[21:58] <asac> great
[21:58] <sergiusens> asac: they are using --channel ubuntu-core/devel-proposed
[21:59] <kickinz1> asac: I take snappy from images for building, I think the last one I took was from r404.
[21:59] <asac> sergiusens: that doesnt even work for me
[21:59] <asac> sergiusens: guess only in beta ppa that works?
[21:59] <sergiusens> asac: they are using an old u-d-f
[21:59] <sergiusens> asac: yeah or no apt update
[21:59] <asac> well, lets wait for next image
[21:59] <asac> hope thats useful
[21:59] <asac> guess we can only hope that things really came together
[22:00]  * asac reboots
[22:00] <kickinz1> sergiusens, I use dnappy-dev/beta yes
[22:01] <kickinz1> sergiusens, ok, I update...
[22:03] <sergiusens> slangasek: I think this is what we need https://code.launchpad.net/~sergiusens/snappy/conflictsPackaging/+merge/257008
[22:06] <kickinz1> so if updated, I can build without getting snappy from images?
[22:06] <kickinz1> sergiusens, ^
[22:13] <kickinz1> sergiusens, I have updated I still get r419... What am I doing wrong?
[22:19] <sergiusens> kickinz1: add-apt-repository ppa:snappy-dev/tools ?
[22:22] <kickinz1> sergiusens, sorry...
[22:24] <jdstrand> kickinz1: you should see seccomp denials if that was it. besides, you are using @unrestricted in the docker-daemon seccomp filter so no seccomp filters (ie, it shouldn't be seccomp)
[22:24] <asac> ok getting 23 it seems
[22:24] <asac> lets see
[22:24] <jdstrand> kickinz1: thinking about it, I bet it is the cgroups
[22:25] <jdstrand> a) docker hasn't been assigned any hardware and b) I doubt it would work with our cgroups implementation
[22:25] <jdstrand> because docker already does stuff with cgroups
[22:26] <jdstrand> (docker really is not a great first framework-- literally everything is an exception)
[22:26] <asac> kickinz1: ok i think 23 might be better... :) lets see
[22:26] <asac> at least i can install docker
[22:27] <kickinz1> the pb is to docker run -it ubuntu.
[22:27] <jdstrand> kickinz1: my feeling is we either need a way to flag the launcher that it shouldn't do anything but aa_change_onexec (ie, aa-exec) or special case docker in bin-path so it uses the old aa-exec
[22:28]  * jdstrand tests by modifying the systemd unit
[22:31] <jdstrand> it's the launcher
[22:31] <jdstrand> I'm going to send mvo an email and CC you guys
[22:31] <kickinz1> jdstrand: thanks
[22:32] <asac> jdstrand: still get bad system call
[22:32] <asac> on 23
[22:32] <asac> latest image
[22:32] <jdstrand> asac: is that capget?
[22:33] <jdstrand> you need ubuntu-core-security-seccomp 15.04.6
[22:33] <asac> jdstrand: ok good news is that the apps seems to work now
[22:33] <asac> at least the hello-world.echo
[22:33] <asac> docker images fails with bad system call though
[22:33] <jdstrand> right
[22:33] <jdstrand> yes, that is fixed
[22:33] <asac> jdstrand: docker?
[22:33] <jdstrand> what kickinz1 and I are talking about is something different
[22:33] <asac> line 11: 1218 Bad system call ...
[22:33] <asac> select_bin ddocker
[22:33] <jdstrand> yes, 15.04.6 fixes the syscall
[22:33] <asac> etc.
[22:33] <asac> jdstrand: thats fixed?
[22:33] <asac> hmm
[22:34] <asac> so we need yet another image?
[22:34] <jdstrand> select_bin?
[22:34] <asac> jdstrand: which package?
[22:34] <jdstrand> what arch is that?
[22:34] <asac> amd64
[22:34] <asac> jdstrand: we spun an image after the most reent ppa upload
[22:34] <jdstrand> can I see the syslog entry?
[22:34] <asac> ok
[22:34] <asac> hmm
[22:34] <asac> have to forward port
[22:36] <asac> jdstrand: Apr 21 22:36:43 localhost kernel: [   66.568721] audit_printk_skb: 12 callbacks suppressed
[22:36] <asac> Apr 21 22:36:43 localhost kernel: [   66.568724] audit: type=1326 audit(1429655803.718:15): auid=1000 uid=1000 gid=1000 ses=1 pid=905 comm="docker.x86_64" exe="/apps/docker/1.6.0.002/bin/docker.x86_64" sig=31 arch=c000003e syscall=228 compat=0 ip=0x7ffc8e52cb4d code=0x0
[22:36] <asac> thats the thing i get when i run docker iamges
[22:37] <asac> 228
[22:37] <asac> probably select_bin
[22:37] <asac> hehe
[22:41] <jdstrand> syscall=228(clock_gettime)
[22:42] <jdstrand> I can adjust that
[22:42] <jdstrand> fyi, sudo sc-logresolve /var/log/syslog
[22:44] <jdstrand> email on docker sent
[22:44] <asac> jdstrand: ?
[22:44] <jdstrand> I will fix that ^ seccomp denial a bit later
[22:44] <jdstrand> asac: I sent it to you too
[22:44] <jdstrand> I have to step away again for a few minutes
[22:52] <asac> kickinz1: what /dev nodes does docker access?
[22:52] <asac> kickinz1: can you strace the command on a normal ubuntu system?
[22:52] <asac> vivid?
[22:52] <asac> to see?
[22:52] <kickinz1> asac: ok
[22:55] <kickinz1> asac:
[22:55] <kickinz1> asac, http://paste.ubuntu.com/10863741/
[22:59] <asac> jdstrand: its not clear to me why you have no problems
[23:00]  * kickinz1 going to bed...
[23:00] <asac> kickinz1: i mean i have the latest image i think
[23:00] <kickinz1> asac: ok, do you want me to test?
[23:00] <asac> orr
[23:00] <asac> err
[23:00] <asac> sorry
[23:00] <asac> kickinz1: no
[23:01] <asac> i meant jdstrand
[23:01] <asac> sleep well
[23:01] <asac> and see you tomnorrow
[23:01] <asac> slangasek: do you know if ubuntu-core-security15.04.6 is on latest image?
[23:01] <kickinz1> asac: ok, will be around for a few minutes still but not too long (pb with uploading owncloud image armhf to docker registry)
[23:02] <asac> jdstrand: i clearly have 15.04.6
[23:02] <kickinz1> asac: for now I've created a docker image for ubuntu:trusty for armhf (I'll change to vivid as soon as everything else works)
[23:02] <asac> guess you say its working on bbb?
[23:03] <slangasek> asac: yes, ubuntu-core-security 15.04.6 is in the latest images on edge (except arm64)
[23:09] <asac> ok i did my first seccomp hackery
[23:09] <asac> enabled clocktime
[23:09] <asac> and now i can runn docker iamges
[23:10] <asac> and i am docker pulling
[23:10] <asac> kickinz1: any idea what it untars at the end?
[23:11] <asac> FATA[0032] Error pulling image (trusty) from ubuntu, Untar exit status 1 operation not permitted
[23:13] <jdstrand> asac: that's fine. it is interesting that you are seeing that seccomp denial in the client where I didn't, but I didn't have a chance to test a lot of it due to the daemon not working well with the launcher
[23:13] <kickinz1> asac: it downloads layers of the image, and then it untar it. It is pulling fgood from registry, and tars are in /var/lib/apps/docker/.tmp/..../xxx/xxx.tar, then it decompresses it, and it must populate /var/lib/apps/docker/aufs with them
[23:13] <jdstrand> I will prepare 15.04.7
[23:14] <kickinz1> ls
[23:14] <jdstrand> we need to not try to fix the launcher for docker at this time and just special case it
[23:15] <jdstrand> if someone wrote a framework for snappy that needed the kinds of perms and did the kinds of things that docker is doing we would almost certainly say 'no'. this is a special case. let's special case it in the easiest way possible now and then see how to deal with this sort of thing going forward
[23:17] <asac> yeah maybe
[23:17] <asac> kickinz1: how can i get logs for docker?
[23:18] <kickinz1> asac, just systemctl stop docker_.... then sudo vi /apps/docker/current/bin/docker.start and uncomment the DEBUG="-D" line
[23:18] <kickinz1> asac, then restart daemon, it will logs to journalctl
[23:18] <kickinz1> asac: really going
[23:19] <asac> bye
[23:32] <asac> jdstrand: what does docker appamrmor get access to in /dev ?
[23:35] <jdstrand> asac: in 'unprivileged' mode: http://paste.ubuntu.com/10863849/
[23:35] <jdstrand> asac: note, most of those are directories, it is just the first 6 lines and the last that are actual files
[23:35] <jdstrand> asac: however, in 'privileged' mode, it has all of /dev
[23:36] <jdstrand> it defaults to unprivileged. there is a command to toggle privileged
[23:36] <jdstrand> docker has the ability to assign hardware to app containers
[23:37] <jdstrand> (which in our snap is reserved for privileged mode)
[23:50] <asac> jdstrand: right. so still dont get whats going on here... do we know that the devnodes that you pasted are really avail there?
[23:51] <jdstrand> asac: what we know is that docker fails to run without them
[23:52] <jdstrand> docker was not designed for snappy and we are shoehorning it into a framework
[23:52] <asac> jdstrand: hmm
[23:52] <asac> jdstrand: so with new launcher those defaults are not getting mapped in?
[23:52] <jdstrand> don't get me wrong, it is useful for people, but its design is not in line with snappy
[23:52] <jdstrand> asac: I don't know why the launcher is breaking docker
[23:53] <jdstrand> asac: I imagine that it is going to be whack-a-mole
[23:53] <asac> jdstrand: right, but do the devnodes get mapped into the launcher cgroup?
[23:53] <jdstrand> ie, we give the devices then it breaks cause of how it uses cgroups
[23:54] <jdstrand> asac: nothing is doing that mapping atm because there is no oem snap that sets those up. even if it did, the udev rule for docker privileged mode would be 'tag everything for docker'
[23:54] <asac> jdstrand: right i get that
[23:54] <asac> jdstrand: can i use hwassign to try doing those dev nodes?
[23:54] <asac> http://paste.ubuntu.com/10863849/
[23:54] <asac> those
[23:55] <asac> i guess i would have to do a find on all those directories :)
[23:55] <jdstrand> as it turns out, no. the command line hw-assign works only with templated policy atm, not hand-crafted policy like docker-daemon has
[23:56] <jdstrand> this is in my personal backlog (there is no trello card)
[23:56] <jdstrand> if that is deemed important, it can be SRUd
[23:57]  * jdstrand adds a trello card
[23:59] <jdstrand> asac: but, cli hw-assign doesn't do the udev stuff. it only adds rules to apparmor policy. as such, with the cgroups implementation, it is currently broken
[23:59]  * jdstrand just realizes that and adds a trello card