| wililupy | Question: I'm trying to build a kernel snap from Kernel Source 4.5 and I need to build custom kernel modules for some drivers. I have successfully compiled the kernel on my build machine, built the headers, and compiled the drivers, but how do I do all of this using Snapcraft? | 00:09 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === xnox_ is now known as xnox | ||
| === Michaela is now known as Mikaela | ||
| === stgraber_ is now known as stgraber | ||
| === chihchunl is now known as chihchun | ||
| === clemensv_ is now known as clemensv | ||
| === mjl_ is now known as mjl | ||
| wililupy | ...helllooo... | 04:12 |
| stevebiscuit | wililupy: it's night time for a lot of the snappy people | 04:51 |
| wililupy | yeah, I figured. I'm having issues building a kernel snap for a vendor, and was hoping to get some guidance. | 04:51 |
| dholbach | good morning | 06:49 |
| === SaMnCo-laptop is now known as SaMnCo-desktop | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| zyga | jdstrand: ping | 11:04 |
| asac | sudo is broken now in classic? | 11:32 |
| asac | (classic)ubuntu@localhost:~$ sudo apt-get install snapcraft bzr | 11:32 |
| asac | sudo: no tty present and no askpass program specified | 11:32 |
| asac | guess related to https://bugs.launchpad.net/snappy/+bug/1564316 | 11:32 |
| ubottu | Launchpad bug 1564316 in Snappy "classic dist-upgrade fails on sudo and tzdata..." [Critical,New] | 11:32 |
| asac | e.g. to the upgrade that came in | 11:32 |
| asac | https://bugs.launchpad.net/snappy/+bug/1564369 | 11:34 |
| ubottu | Launchpad bug 1564369 in Snappy "sudo broken in latest classic" [Undecided,New] | 11:34 |
| asac | mdeslaur: ^ | 11:36 |
| asac | anything you can think of being wrong with your sudo upload? | 11:36 |
| mdeslaur | asac: not off hand, no. needs investigating | 11:38 |
| asac | its hard blocker on developing snappy | 11:38 |
| asac | or on snappy | 11:38 |
| asac | anyway, lets see if one of snappy folks gets on i | 11:38 |
| asac | t | 11:38 |
| asac | mdeslaur: no complains from normal ubuntuf olks? | 11:38 |
| * asac doesnt have rthe latest sudo yet on xenial desktop and wonders if i should rather not upgrade | 11:39 | |
| mdeslaur | asac: nope, works fine on regular desktop | 11:39 |
| asac | ok let me upgrade | 11:40 |
| asac | :) | 11:40 |
| asac | lets hope you are right | 11:40 |
| asac | mdeslaur: were there any snappy changes in your merge? | 11:40 |
| asac | or in the version that we had before :) | 11:40 |
| mdeslaur | there's nothing snappy-specific in the sudo package, no | 11:41 |
| asac | ok | 11:41 |
| asac | odd | 11:41 |
| mdeslaur | do you get any apparmor denials? | 11:41 |
| asac | lets wait for snappy crew to come in | 11:41 |
| * ogra_ sees the same on a rpi here | 11:42 | |
| mdeslaur | what's the output of "tty" | 11:43 |
| ogra_ | (classic)ubuntu@localhost:~$ tty | 11:44 |
| ogra_ | not a tty | 11:44 |
| ogra_ | (classic)ubuntu@localhost:~$ | 11:44 |
| mdeslaur | well, there you go | 11:44 |
| ogra_ | well, that was guessable from the error :P | 11:44 |
| mdeslaur | and downgrading sudo works? | 11:44 |
| mdeslaur | did you get a new glibc too? | 11:45 |
| jdstrand | mdeslaur: fyi, 'snappy shell classic' does not run under apparmor (it is just a command to get into an ubuntu chroot) | 11:45 |
| * ogra_ only just did "snappy enable-classic" ... this was a fresh install | 11:45 | |
| ogra_ | you have to ask asac for an upgrade log | 11:45 |
| jdstrand | bug #1564316 has the upgrade log | 11:45 |
| ubottu | bug 1564316 in Snappy "classic dist-upgrade fails on sudo and tzdata..." [Critical,New] https://launchpad.net/bugs/1564316 | 11:45 |
| ogra_ | ah | 11:46 |
| * jdstrand notes he hasn't tried any of this yet | 11:46 | |
| jdstrand | I wonder if it is the pt_chown removal | 11:46 |
| ogra_ | well, i wonder why it mounts /etc/sudoers at all | 11:47 |
| asac | we cnanot downgrade | 11:47 |
| asac | i had to install fresh | 11:47 |
| asac | because dist-upgrade failed | 11:47 |
| asac | because sudoers cannot be written on snappy | 11:47 |
| asac | ogra_: it does that so you can sudo apt-get install | 11:48 |
| ogra_ | yeah, it shouldnt bind mount it | 11:48 |
| asac | we could have a copy | 11:48 |
| asac | sure | 11:48 |
| asac | think thats mvos work | 11:48 |
| ogra_ | why ? | 11:48 |
| asac | just said... think we could create a copy :) | 11:48 |
| ogra_ | the relevant info isnt in there | 11:48 |
| ogra_ | on snappy | 11:48 |
| asac | so i remember initially in classic you couldnt sudo apt-get install | 11:49 |
| asac | then mvo landed something | 11:49 |
| asac | maybe it was this :) | 11:49 |
| * jdstrand is unable to enable classic | 11:49 | |
| ogra_ | the relevant file is /etc/sudoers.d/90-cloud-init-users | 11:49 |
| asac | jdstrand: it works well | 11:49 |
| jdstrand | Get https://images.linuxcontainers.org/meta/1.0/index-system: dial tcp 192.99.34.219:443: i/o timeout | 11:49 |
| asac | sudo snappy enable-classic | 11:49 |
| asac | :) | 11:49 |
| asac | oh we still use those images | 11:49 |
| asac | heh | 11:49 |
| ogra_ | not /etc/sudoers | 11:49 |
| jdstrand | heh, I know, except not :) | 11:49 |
| asac | thast a critical bug too | 11:49 |
| ogra_ | yes :( | 11:50 |
| asac | lets put bets on how likely this is still in when we release :) | 11:50 |
| asac | anyway | 11:50 |
| ogra_ | well, we need an arm64 image at least | 11:50 |
| asac | jdstrand: just try again | 11:50 |
| * jdstrand has tried 8 times | 11:50 | |
| asac | its amateur server that probably will come back | 11:50 |
| asac | :P | 11:50 |
| * jdstrand keeps trying | 11:50 | |
| asac | (sorry for being ironic) | 11:50 |
| jdstrand | ah, the 9th time's the charm | 11:50 |
| asac | see | 11:51 |
| asac | CDN | 11:51 |
| asac | i am sure though its your internet net | 11:51 |
| asac | :P | 11:51 |
| asac | cool thanks for trying | 11:51 |
| jdstrand | I can confirm the bug | 11:51 |
| asac | great... that makes it three :) | 11:52 |
| ogra_ | sudo umount /writable/classic/etc/sudoers | 11:52 |
| ogra_ | sudo mount --bind /etc/sudoers.d /writable/classic/etc/sudoers.d | 11:52 |
| ogra_ | then try again | 11:52 |
| asac | that works? | 11:52 |
| ogra_ | should work | 11:52 |
| asac | the upgrade or the sudo? | 11:52 |
| asac | ok | 11:52 |
| ogra_ | sudo | 11:52 |
| asac | upgrade would work too i guess | 11:52 |
| ogra_ | yeah | 11:52 |
| asac | or at least less likely to conflict aka break | 11:53 |
| jdstrand | I can confirm ogra_'s commands fix it | 11:53 |
| jdstrand | it is still not a tty, but sudo works | 11:54 |
| asac | ogra_: added it as workaround giving credits to you | 11:54 |
| asac | ogra_: https://bugs.launchpad.net/snappy/+bug/1564369 | 11:54 |
| ubottu | Launchpad bug 1564369 in Snappy "sudo broken in latest classic" [Critical,New] | 11:54 |
| mdeslaur | huh, that's odd | 11:54 |
| asac | think now we can wait for mvo to come back unless you guys know what to do | 11:54 |
| ogra_ | mdeslaur, nah, not odd | 11:54 |
| ogra_ | mdeslaur, /etc/sudoers lives in a squashfs and then gets bind mounted into the container | 11:54 |
| asac | bah | 11:54 |
| ogra_ | so it is ro underneath | 11:54 |
| asac | i cannot save the workaround | 11:54 |
| asac | launchpad!!! | 11:55 |
| asac | posting as comment instead then | 11:55 |
| asac | also not working :( | 11:55 |
| ogra_ | re-login ? | 11:55 |
| asac | why? i used lp a few minutes ago | 11:55 |
| asac | WORKAROUND (credits to ogra): | 11:55 |
| asac | ubuntu@localhost:~$ sudo umount /writable/classic/etc/sudoers | 11:55 |
| asac | ubuntu@localhost:~$ sudo mount --bind /etc/sudoers.d /writable/classic/etc/sudoers.d | 11:55 |
| ogra_ | heh | 11:56 |
| jdstrand | ogra_: that makes sense for 'sudo apt-get upgrade' in the chroot failing, but not sure how it explains sudo not working in a fresh 'enable-classic' | 11:56 |
| asac | well needed to paste it somewhere so it doesnt get lost :) | 11:56 |
| ogra_ | jdstrand, yeah, thats indeed a bit weird, especially the tty bit | 11:56 |
| jdstrand | but tty returns 'not a tty' before and after your workaround | 11:57 |
| jdstrand | that doesn't seem to be the issue... | 11:57 |
| mdeslaur | what's in the file in the sudoers.d directory? | 11:57 |
| asac | o/ | 11:57 |
| asac | ffox is king of lp | 11:57 |
| asac | mdeslaur: two files | 11:57 |
| jdstrand | mdeslaur: with ogra's bind mount, it is empty | 11:57 |
| ogra_ | shouldnt | 11:58 |
| jdstrand | sorry, I lied | 11:58 |
| * ogra_ waits for apt-get install snapcraft to finish | 11:58 | |
| jdstrand | I wasn't root do didn't get bash completion | 11:58 |
| asac | mdeslaur: | 11:58 |
| asac | root@localhost:/home/ubuntu# cat /etc/sudoers.d/10-ubuntu-core-secure-path | 11:58 |
| asac | Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snaps/bin" | 11:58 |
| asac | root@localhost:/home/ubuntu# cat /etc/sudoers.d/90-cloud-init-users | 11:58 |
| asac | # Created by cloud-init v. 0.7.7 on Thu, 31 Mar 2016 11:23:15 +0000 | 11:58 |
| asac | # User rules for ubuntu | 11:58 |
| asac | ubuntu ALL=(ALL) NOPASSWD:ALL | 11:58 |
| asac | and README | 11:58 |
| asac | yay upgrading xenial proper also failed ;) | 11:58 |
| mdeslaur | ah, no the NOPASSWD alleviated the need for a tty | 11:58 |
| asac | cups-browsed :0 | 11:59 |
| ogra_ | oh, indeed ! | 11:59 |
| asac | not sudo... so no panic :) | 11:59 |
| asac | but why did this change? | 11:59 |
| asac | where did we change something? | 11:59 |
| asac | before we had sudoers bindmounted | 11:59 |
| mdeslaur | it didn't change, it just never properly handled a sudo package upgrade properly | 11:59 |
| asac | wait | 12:00 |
| asac | tahts not true | 12:00 |
| asac | i install fresh classic | 12:00 |
| asac | which just downloads a prebuilt image and unpacks | 12:00 |
| asac | no uptgrade etc. | 12:00 |
| asac | and then i got the sudo problem | 12:00 |
| asac | upgrading wasnt possible at all | 12:00 |
| asac | so its not upgrade issue | 12:00 |
| jdstrand | yeah, that is what I was saying | 12:00 |
| asac | at least not an upgrade on my side | 12:00 |
| ogra_ | yeah, there must still be something wrt tty | 12:00 |
| asac | something changed for sure | 12:00 |
| asac | somewhere :) | 12:00 |
| mdeslaur | hrm | 12:00 |
| jdstrand | I wonder if 10-ubuntu-core-secure-path isn't being copied into place with enable-classic or something | 12:01 |
| jdstrand | so then you need a password | 12:01 |
| ogra_ | remove the bind mount and check from outsuide the container ;) | 12:01 |
| asac | maybe mr. graber though hacked up his container tarball ... just so we stop using those unsupported things | 12:01 |
| ogra_ | ubuntu@localhost:~$ sudo ls /writable/classic/etc/sudoers.d | 12:02 |
| ogra_ | README | 12:02 |
| ogra_ | but thats not the issue | 12:02 |
| jdstrand | yeah | 12:02 |
| ogra_ | there is something wonky about ttys | 12:02 |
| jdstrand | ogra_: I think that explains it | 12:02 |
| ogra_ | (classic)ubuntu@localhost:~$ tty | 12:02 |
| ogra_ | not a tty | 12:02 |
| * ogra_ has a non upgraded container, gimme a minute | 12:02 | |
| jdstrand | ogra_: we aren't bind mounting /etc/sudoers.d so 90-cloud-init-users isn't getting in there | 12:03 |
| ogra_ | ubuntu@localhost:~$ mount|grep sudoers | 12:03 |
| ogra_ | /dev/mmcblk0p2 on /etc/sudoers.d type ext4 (rw,relatime,data=ordered) | 12:03 |
| ogra_ | /dev/loop0 on /writable/classic/etc/sudoers type squashfs (ro,relatime) | 12:03 |
| ogra_ | thats with the old classic container | 12:03 |
| jdstrand | ogra_: but, why is 90-cloud-init-users there at all on my system... | 12:04 |
| ogra_ | ubuntu@localhost:~$ sudo ls /writable/classic/etc/sudoers.d/ | 12:04 |
| ogra_ | README | 12:04 |
| ogra_ | ubuntu@localhost:~$ snappy shell classic | 12:04 |
| ogra_ | ... | 12:04 |
| ogra_ | (classic)ubuntu@localhost:~$ tty | 12:04 |
| ogra_ | not a tty | 12:04 |
| jdstrand | like, why is the ubuntu user not supposed to enter a password? | 12:04 |
| asac | jdstrand: we use cloud-init still no? | 12:04 |
| ogra_ | (classic)ubuntu@localhost:~$ sudo ls | 12:04 |
| ogra_ | [sudo] password for ubuntu: | 12:04 |
| ogra_ | ... | 12:04 |
| ogra_ | so here it works | 12:04 |
| asac | jdstrand: i think we never ask for password in snappy for sudo? | 12:04 |
| asac | asked | 12:04 |
| ogra_ | despite not having a tty | 12:04 |
| asac | hmm | 12:04 |
| asac | not true indeed | 12:05 |
| jdstrand | asac: sure, but haven't we always required a password for sudo? | 12:05 |
| asac | so in classic we dont | 12:05 |
| ogra_ | in classic we obviously did | 12:05 |
| jdstrand | I'm talking outside the classic shell | 12:05 |
| ogra_ | outside we dont | 12:05 |
| asac | ogra_: we asked for pass? | 12:05 |
| ogra_ | yeah | 12:05 |
| asac | oh :) | 12:05 |
| ogra_ | see above | 12:05 |
| * asac old | 12:05 | |
| ogra_ | thats a container from about a week ago | 12:05 |
| ogra_ | not upgraded | 12:05 |
| asac | so what is expected experience? i assume we want same behaviour for sudo in and outside container? | 12:06 |
| ogra_ | but even there tty says there is no tty | 12:06 |
| asac | e.g. either pass or not? | 12:06 |
| jdstrand | meh, even 15.04 has 90-cloud-init-users | 12:06 |
| ogra_ | inside the classic container ? | 12:06 |
| * ogra_ has never tried classic on 15.04 | 12:06 | |
| asac | there isnt classic | 12:07 |
| ogra_ | right | 12:07 |
| asac | on 15.04 | 12:07 |
| asac | cloud-init is our first boot tool | 12:07 |
| ogra_ | i thought i missed something | 12:07 |
| asac | it has always been there | 12:07 |
| jdstrand | ogra_: not what I meant. I got distracted by the fact that there is no password prompt for sudo at all in snappy | 12:07 |
| ogra_ | sadly, yeah :PO | 12:07 |
| ogra_ | jdstrand, thats a cloud init config thing | 12:07 |
| jdstrand | ogra_: is that something with udf options? | 12:08 |
| ogra_ | nope, something with the cloud init defaults | 12:08 |
| jdstrand | cause jeez, I have two live systems with this | 12:08 |
| ogra_ | /var/lib/cloud/seed/nocloud-net/user-data and /var/lib/cloud/seed/nocloud-net/meta-data are pre-created | 12:08 |
| ogra_ | and iirc theer is an option you can set in user-data to make it ask | 12:09 |
| * jdstrand adds this as a todo to discuss with mvo | 12:09 | |
| * jdstrand edits this file on his live systems | 12:09 | |
| jdstrand | ogra_: ok, so, back to asac's issue | 12:10 |
| ogra_ | the ubuntu user is in the sudp group by default so dropping the 90-cloud-init-users would be fine | 12:10 |
| jdstrand | ogra_: I guess something in earlier image worked and something in latest doesn't | 12:10 |
| jdstrand | ogra_: I'm on 16.04+20160321.17-27 on the host here | 12:11 |
| jdstrand | if I enable-classic and shell classic, I have the no tty issue | 12:11 |
| ogra_ | you could try sideloading a newer ubuntu-core (breaks upgrades though) | 12:11 |
| jdstrand | ogra_: your bind mount papers over the underlying issue I think | 12:12 |
| ogra_ | it does | 12:12 |
| jdstrand | but at least it allows people to keep working, so that's good :) | 12:12 |
| jdstrand | ogra_: I can say that /usr/lib/pt_chown does not exist in the container | 12:12 |
| * jdstrand wishes he had an earlier classic | 12:12 | |
| ogra_ | wow | 12:13 |
| jdstrand | /usr/lib/pt_chown is not supposed to exist btw | 12:13 |
| ogra_ | looking at the cloud-init docs it seems thats actually a default | 12:13 |
| jdstrand | ogra_: right, I knew that is what they set | 12:13 |
| ogra_ | how awful | 12:13 |
| jdstrand | I am a lot less sure that is the correct default for snappy | 12:13 |
| jdstrand | ogra_: I forget their rationale. smoser could certainly remember | 12:14 |
| ogra_ | he's on vacation :) | 12:14 |
| jdstrand | ugh | 12:15 |
| ogra_ | but i guess there is a reason and there were discussions ... so i wont bother :) | 12:15 |
| jdstrand | that is why I want to bring it up with mvo rather than filing a bug, doing the mailing list, etc | 12:16 |
| jdstrand | but it's a trap! | 12:16 |
| jdstrand | :) | 12:16 |
| ogra_ | hah | 12:16 |
| jdstrand | I have to know I need to edit that file | 12:16 |
| jdstrand | I don't think the snappy docs mention this anywhere | 12:17 |
| zyga | jdstrand: hey | 12:17 |
| ogra_ | you could boot with cloud-init=disabled on the kernel cmdline ;) | 12:17 |
| jdstrand | zyga: hey | 12:18 |
| ogra_ | (though then you end up without ssh keys ... iirc thats the only thing we need cloud-init for nowadays) | 12:18 |
| zyga | jdstrand: I posted some cleanups and seccomp | 12:18 |
| zyga | jdstrand: and I'm about to post dbus | 12:18 |
| jdstrand | zyga: I was actually going to respond to your ping and then all that ^ came up at the same time | 12:18 |
| zyga | jdstrand: no worries :) | 12:18 |
| zyga | jdstrand: I already forgot what I wanted then | 12:18 |
| jdstrand | zyga: yeah, I was going through the emails for that | 12:18 |
| jdstrand | ogra_: ah, so, interesting. I happened to have a vm with a previous enable-classic that hasn't been upgraded | 12:22 |
| jdstrand | (classic)ubuntu@snappy-20160324-amd64:~$ tty | 12:22 |
| jdstrand | not a tty | 12:22 |
| jdstrand | (classic)ubuntu@snappy-20160324-amd64:~$ sudo uptime | 12:22 |
| jdstrand | [sudo] password for ubuntu: | 12:22 |
| jdstrand | 12:21:46 up 0 min, 1 user, load average: 0.43, 0.11, 0.04 | 12:22 |
| ogra_ | yeah | 12:22 |
| ogra_ | thats what i said above | 12:22 |
| jdstrand | so, no tty but it still works | 12:22 |
| jdstrand | password prompting works that is | 12:22 |
| ogra_ | the bind mounts are all the same on both | 12:23 |
| jdstrand | there is no /usr/lib/pt_chown there either, so that should be unrelated | 12:23 |
| ogra_ | so nothing changed wrt /dev/pts or so | 12:23 |
| jdstrand | I can confirm that | 12:25 |
| jdstrand | /dev/ptmx is 0666 and nothing in /dev/pts | 12:25 |
| jdstrand | I suspect we actually want to mount /dev/pts/ptmx though | 12:26 |
| ogra_ | yeah | 12:26 |
| ogra_ | ubuntu@localhost:~$ sudo mount --bind /dev/pts /writable/classic/dev/pts | 12:27 |
| ogra_ | ubuntu@localhost:~$ snappy shell classic | 12:27 |
| ogra_ | ... | 12:27 |
| ogra_ | (classic)ubuntu@localhost:~$ sudo ls | 12:27 |
| ogra_ | [sudo] password for ubuntu: | 12:27 |
| ogra_ | ... | 12:27 |
| ogra_ | ubuntu@localhost:~$ sudo umount /writable/classic/dev/pts | 12:28 |
| ogra_ | ubuntu@localhost:~$ snappy shell classic | 12:28 |
| ogra_ | (classic)ubuntu@localhost:~$ sudo ls | 12:28 |
| ogra_ | sudo: no tty present and no askpass program specified | 12:28 |
| ogra_ | so yes, that fixes it properly | 12:28 |
| jdstrand | yeah, so bind mounting /dev/pts /writable/classic/dev/pts 'solves' the tty issue (I suspect we actually want a devpts newinstance,ptmxmode=0666,gid=5 mount instead of a bind mount though | 12:28 |
| jdstrand | ) | 12:28 |
| ogra_ | in any case something inside the snappy enable-classic chain ... | 12:29 |
| jdstrand | yeah | 12:29 |
| jdstrand | ok, I'm wandering off to look at zyga's PRs | 12:29 |
| zyga | jdstrand: cool :) | 12:29 |
| zyga | jdstrand: ah, I wanted to ask about dbus and developer mode | 12:30 |
| zyga | jdstrand: do we have plans to support anything similar for dbus? | 12:30 |
| jdstrand | zyga: I'll first say that I'm fairly in the dark wrt all things developer mode. All I know about it is that it is supposed to be per-snap complain mode for the security sandbox | 12:31 |
| zyga | jdstrand: yes, that's accurate so far | 12:31 |
| jdstrand | zyga: with that said, I think it is sufficient to have apparmor in complain mode for dbus | 12:31 |
| zyga | jdstrand: ok | 12:31 |
| jdstrand | ie, let's not fiddle with dbus bus policy | 12:31 |
| zyga | jdstrand: we don't have any dbus snippets yet (nothing uses it) but I suspect we'll need something fairly soon | 12:32 |
| jdstrand | zyga: I get pinged by the bluez, nm, pulse, mir, etc guys all the time and been telling them once this interfaces (and really the state engine) stuff all lands, we can circle back to them | 12:33 |
| jdstrand | zyga: so very soon you and I will have an opportunity to check out the dbus interface | 12:33 |
| jdstrand | zyga: I just looked at https://dbus.freedesktop.org/doc/dbus-daemon.1.html. dbus bus policy doesn't (currently) have a concept of complain mode. it is either deny or allow | 12:36 |
| zyga | ok, that's good to know, thansk | 12:37 |
| zyga | I'll put this into the code as a note | 12:37 |
| jdstrand | zyga: so don't do anything for developer mode and dbus. I suspect a dbus service author is going to be just fine with tuning the bus policy as needed so long as we have apparmor in complain mode | 12:37 |
| jdstrand | perhaps some day if it becomes a requirement dbus can be modified to allow but log (ie, support complain) | 12:38 |
| zyga | jdstrand: I have one more issue (udev) but I wrote it down and we can discuss it when reviweing the patches | 12:38 |
| jdstrand | zyga: I had some questions regarding udev, cgroups and the launcher that can probably wait until then. there is an interesting intersection of apparmor, udev and the launcher that we need to be careful about | 12:42 |
| jdstrand | zyga: cause as it stands now, the launcher won't setup a cgroup if /var/lib/apparmor/clicks/%s.json.additional doesn't have a particular string | 12:43 |
| zyga | _clicks_? | 12:43 |
| jdstrand | yes | 12:43 |
| zyga | that's not good | 12:43 |
| zyga | given the time frame, do we have hands on the launcher? | 12:43 |
| jdstrand | my hands are on the launcher all the time lately | 12:44 |
| jdstrand | I'm not sure what you are referring to though | 12:44 |
| jdstrand | I'll put it another way | 12:44 |
| zyga | ah, I wasn't sure, I recall you were transitioning but were still busy as a manager | 12:44 |
| jdstrand | I'm fine with updating the launcher, but it is going to need to make a choice to apply a cgroup or not | 12:45 |
| jdstrand | zyga: I am functioning as interim manager. people have given me some space, but it is more like I have 1.5 jobs atm | 12:45 |
| jdstrand | zyga: anyway, historically, as you know, constantly recompiling the apparmor profile because a usb device came up differently or was unplugged, etc, etc was not viable. so we came up with the idea to add devices to an app-specific cgroup (fine) | 12:48 |
| zyga | yes | 12:48 |
| jdstrand | zyga: the idea was then, when a device was assigned to the snap, apply lenient apparmor policy for /dev, and then just let device cgroups handle the mediation (also fine) | 12:49 |
| zyga | right | 12:49 |
| jdstrand | zyga: so, then docker came along and broke when it ws run under a cgroup (iirc) | 12:49 |
| jdstrand | so the idea was, have the launcher conditionally setup the cgroup *if* it detected the lenient apparmor policy | 12:50 |
| jdstrand | that lenient policy was applied to /var/lib/apparmor/clicks/%s.json.additional | 12:50 |
| jdstrand | so the launcher would look in there | 12:50 |
| zyga | ah | 12:51 |
| zyga | man, | 12:51 |
| jdstrand | I think what we could do instead is look in the udev db to see if any devices are assigned | 12:51 |
| jdstrand | and make that the conditional | 12:51 |
| zyga | I'm inclined to agree | 12:51 |
| zyga | but I'd like to sit down and write down variou things we need to and can do and see if it all adds up | 12:51 |
| jdstrand | sure | 12:52 |
| jdstrand | cause the thing is, you'll want an apparmor snippet for the lenient /dev policy on device assignment since the launcher isn't going to modify policy | 12:52 |
| jdstrand | device grant* | 12:53 |
| jdstrand | and on revoke, remove that | 12:53 |
| jdstrand | zyga: I'll add a card for my to adjust snappy_udev_setup_required() to check udev for assignments | 12:53 |
| jdstrand | s/my/me/ | 12:54 |
| jdstrand | zyga: but I'll wait to act on it til I hear back from you | 12:54 |
| jdstrand | I have several MPs for the launcher that are in play, so I can keep moving forward | 12:54 |
| jdstrand | this area is admittedly too twisty, but whenever we get apparmor profile composition, we can get rid of this | 12:55 |
| jdstrand | (there is a bug on this btw) | 12:56 |
| jdstrand | that is almost certainly not a 16.10 thing | 12:57 |
| jdstrand | so we'll need to get this right | 12:57 |
| jdstrand | zyga: ^ | 12:57 |
| * jdstrand makes sure profile composition is in the planning doc tyhicks and I are putting together | 12:57 | |
| zyga | jdstrand: when you say it is not a 16.10 thing, do you mean it needs to be done for 16.04 or that it will take more time than 16.10? | 12:59 |
| jdstrand | zyga: I mean I doubt it will even be done for 17.04 (yes, *17*) | 13:00 |
| jdstrand | we need to live with this udev/cgroup stuff for a while yet | 13:01 |
| zyga | ouch | 13:01 |
| zyga | ok | 13:01 |
| josepht | what is the preferred way on 16.04 to do initialization (think add user to extrausers, add ssh public keys, etc.) for a snap? | 13:01 |
| zyga | jdstrand: you should join our standups | 13:04 |
| zyga | jdstrand: perhaps not today (too late) but I think it would be useful | 13:04 |
| === _bjf is now known as bjf | ||
| jdstrand | if now is too late, then every day is too late | 13:09 |
| jdstrand | I started very early today. my normal start of day is 9 minutes ago | 13:09 |
| ogra_ | josepht, you cant | 13:11 |
| kyrofa | Good morning | 13:12 |
| zyga | jdstrand: we just started, I think you could still join reguarly | 13:12 |
| popey | should webdm start on boot? if not, how do I start it, and what port does it run on? | 13:13 |
| ogra_ | (and you shouldnt, everything inside a snap will run as root or if it is a user executable binary, as the user that execs it) | 13:13 |
| beowulf | popey: snappy install webdm, then it should be on webdm.local:4200 | 13:13 |
| ogra_ | popey, it should (but there seem to be issues with platforms that use WLAN) ... port is 4200 | 13:13 |
| popey | aha! | 13:14 |
| popey | hm, all wired here. works on my pi 2 but not pi3, your image ogra_ | 13:15 |
| popey | didn't start it seems | 13:15 |
| popey | I get no updates on that pi3 image either, wondering if I should expect any? | 13:17 |
| jdstrand | zyga: fyi, https://bugs.launchpad.net/ubuntu/+source/ubuntu-core-launcher/+bug/1564401 | 13:18 |
| ubottu | Launchpad bug 1564401 in ubuntu-core-launcher (Ubuntu) "launcher does not apply cgroups on 16.04" [High,Triaged] | 13:18 |
| zyga | jdstrand: since you already look at that area | 13:19 |
| zyga | jdstrand: how would it work if two separate apps/snapps wanted to get a device in their cgroup? | 13:19 |
| ogra_ | popey, the one from my people.u.c ? | 13:20 |
| zyga | jdstrand: the rules that we'd make today, from what I know about udev, would overwrite one another | 13:20 |
| jdstrand | zyga: I assigned that to me already | 13:20 |
| ogra_ | popey, i think that still has sideloaded bits ... which would prevent automatic upgrades | 13:20 |
| zyga | jdstrand: I might be getting this wrong | 13:20 |
| zyga | jdstrand: but just something raised my eyebrow yesterday | 13:21 |
| jdstrand | zyga: I'm not a udev expert, but would hope that the rules were written such that they would be cumulative. ie, a device has multiple tags. so a device is tagged with foo and bar, but not baz | 13:21 |
| zyga | jdstrand: well, now there are no rules | 13:21 |
| popey | ogra_: yeah, it's all listed as sideloaded | 13:21 |
| jdstrand | zyga: I suggest asking pitti about that part (he came up with this snappy tagging scheme) | 13:21 |
| zyga | jdstrand: but as soon as we want to write some, the simplistic snippets might require parsing/processing to really express this | 13:21 |
| zyga | jdstrand: ok, noted | 13:21 |
| jdstrand | zyga: that said, I think for 15.04 the decision was a device could only be assigned to a single snap | 13:22 |
| zyga | jdstrand: mmmmmm | 13:22 |
| zyga | jdstrand: that's good to know | 13:22 |
| zyga | jdstrand: anyway, I've got this written down and I'll explore this further with udev code soon | 13:22 |
| jdstrand | zyga: we need mvo and pitti to comment-- I was only on the periphery of that and reviewed the code | 13:22 |
| ogra_ | popey, right, so you could only update it manually ... (or re-build a fresh image witgh all bits from the store) | 13:23 |
| popey | is there a plan to make a working image? | 13:23 |
| ogra_ | once i find the time | 13:24 |
| ogra_ | or once elopio gets the auto-uploading of snaps to work | 13:25 |
| popey | ij | 13:25 |
| ogra_ | whatever happens first :) | 13:25 |
| vila | elopio: https://github.com/ubuntu-core/snapcraft/pull/414 failed the example tests again, not sure I understand what is going on there, can you help ? | 13:26 |
| josepht | ogra_: I'm trying to make a git snap. It sounds like I'd only be able to do a basic read-only mirroring server or an HTTP[S] authenticated push/pull server by pulling in a static web server and somehow managing an application level authentication scheme. | 13:33 |
| ogra_ | josepht, yeah, i fear ... unless jdstrand can tell you a method to use users from the actual system in snaps | 13:36 |
| ogra_ | (i have a similar prob trying to package dovecot since a while) | 13:36 |
| josepht | ogra_: I still wonder about initialization. Perhaps I'm going at it wrong and should make my service idempotently setup it's directory structure, clone repos, etc. | 13:39 |
| jdstrand | snappy doesn't currently provide access to the pam stack in this manner | 13:39 |
| ogra_ | package a bzr server instead, just needs sshd after all ;) | 13:42 |
| zyga | jdstrand: https://github.com/ubuntu-core/snappy/pull/767 (dbus) | 13:51 |
| jdstrand | niemeyer: hey, thanks for the merges. if there is anything for me to do in that card, please add me to it | 14:02 |
| niemeyer | jdstrand: Thank you for the branches! | 14:03 |
| niemeyer | jdstrand: I think some of the renames there make sense, but they are trivial and we can easily do on this side | 14:03 |
| niemeyer | jdstrand: One thing I was just wondering which you might have some info on regards the "unity7" interface | 14:03 |
| niemeyer | jdstrand: Is that unity7 or unity? | 14:03 |
| niemeyer | jdstrand: In other words, do we expect unity7 software to talk to unity8? | 14:04 |
| jdstrand | niemeyer: I chose unity7 to differentiate it from unity8 which would have completely different policy | 14:04 |
| niemeyer | jdstrand: Why/how would it be different? | 14:04 |
| jdstrand | unity7 is X and unity8 is mir. unity8 has things like content-hub, etc that unity7 doesn't. I was thinking unity8 is basically the existing touch policy whereas unity7 is something considerably more lenient | 14:05 |
| zyga | jdstrand: remember that we can use "unity" as an interface and require "version" attribute to hide the nasty details | 14:06 |
| jdstrand | I don't think they should be combined since we wouldn't want to give a designed for unity8 app the wide access required for unity7 | 14:06 |
| zyga | jdstrand: but then again we cannot yet require "unity version 7" on the consuming side | 14:06 |
| jdstrand | zyga: ok, I actually didn't know that | 14:06 |
| zyga | jdstrand: there's some support planned for $version: 7 (eg) on a plug | 14:07 |
| zyga | jdstrand: but it's not 16.04 material | 14:07 |
| zyga | jdstrand: but the snippets we hand out can easily look at attributes | 14:07 |
| jdstrand | perhaps this is a refinement we can talk about once we are enforcing these interfaces and all the glue/etc is working? | 14:07 |
| niemeyer | zyga: I'm not entirely sure it would make sense in the case described | 14:08 |
| jdstrand | if you want to change it to 'unity', that's fine. we can add the version at a later date and if that doesn't pan out, add a unity8 separate from unity for that | 14:08 |
| niemeyer | zyga: If indeed most software using one cannot use the other, there's little reason to munge them under a single name | 14:08 |
| zyga | mmmm | 14:08 |
| zyga | is that really true? I was under the impression that SDK apps work on both versions without modification | 14:09 |
| niemeyer | zyga: It's not just a parameter (a path, a max speed limit, etc), but a different protocol altogether | 14:09 |
| niemeyer | <jdstrand> unity7 is X and unity8 is mir. | 14:09 |
| niemeyer | ? | 14:09 |
| jdstrand | zyga: sdk apps may work without modification but the underlying systems in use are different | 14:10 |
| zyga | jdstrand: right, that is true | 14:10 |
| zyga | well, this was just a note that we have the ability, perhaps it doesn't makes sense to use it in this case | 14:10 |
| jdstrand | and those underlying systems greatly change the access to the rest of the system | 14:10 |
| jdstrand | sure | 14:10 |
| jdstrand | we can discuss at a more appropriate time | 14:11 |
| jdstrand | but, that is why I named it unity7 | 14:11 |
| niemeyer | jdstrand: Makes sense, thanks | 14:11 |
| jdstrand | to differentiate between it and unity8. I envisioned unity7 is what I implemented and unity is unity8 down the line | 14:11 |
| niemeyer | zyga: If the same software might use both, it's a question worth asking down the line.. today what we have is simpler | 14:11 |
| jdstrand | but we can do unity as what is implemented and then decide if unity8 down the line vs unity with version if you prefer | 14:12 |
| niemeyer | jdstrand: Yeah, "unity" being the new one makes sense | 14:12 |
| zyga | yeah, let's get basics working now | 14:12 |
| zyga | and polish this later if there's something we want to change | 14:12 |
| niemeyer | jdstrand: Also, just for the record, note the interface might return different snippets (different policy) depending on a parameter of the interface | 14:12 |
| niemeyer | jdstrand: Not that we should change this now, but it's a tricky that will come handy often | 14:13 |
| niemeyer | s/tricky/trick | 14:13 |
| jdstrand | niemeyer: ack | 14:13 |
| jdstrand | niemeyer: curious on this point-- right now I thought we would have this | 14:14 |
| jdstrand | apps: | 14:14 |
| jdstrand | foo: | 14:14 |
| jdstrand | plugs: [unity7] | 14:14 |
| jdstrand | but what you are suggesting means: | 14:14 |
| jdstrand | apps: | 14:14 |
| jdstrand | foo: | 14:14 |
| jdstrand | plugs: [unity] | 14:14 |
| jdstrand | plugs: | 14:14 |
| jdstrand | unity: | 14:14 |
| jdstrand | interface: unity | 14:15 |
| jdstrand | version: 8 | 14:15 |
| jdstrand | is that right? | 14:15 |
| * jdstrand has a followup question if it is | 14:15 | |
| zyga | jdstrand: (even without the interface: unity) (that's the default) | 14:15 |
| niemeyer | jdstrand: That's right | 14:16 |
| jdstrand | zyga: ok, I have two things I am getting at here. 1) the top-level 'plus' is not normally needed unless you are tweaking parameters and 2) if there are tweakable parameters (like version), is there a default (eg, '8') so that you don't need the top-level 'plugs'? | 14:17 |
| niemeyer | jdstrand: Or, that's feasible, rather | 14:17 |
| jdstrand | s/plus/plugs/ | 14:17 |
| zyga | jdstrand: there are no defaults yet | 14:17 |
| niemeyer | zyga: Hm? | 14:17 |
| zyga | niemeyer: no defaults for attributes | 14:18 |
| niemeyer | zyga: The interface can trivially default to something | 14:18 |
| niemeyer | zyga: "if version is unset, use 8" | 14:18 |
| zyga | jdstrand: if the interface requires that attribute to be present (say) then it would not validate | 14:18 |
| zyga | jdstrand: sure | 14:18 |
| zyga | er | 14:18 |
| zyga | niemeyer: ^ sure | 14:18 |
| jdstrand | ok | 14:18 |
| jdstrand | that might get interesting (I'm not blocking or anything, just observing) | 14:18 |
| zyga | niemeyer: the interface can do that; what I meant to say is that we're not using this capability yet | 14:18 |
| zyga | but it sure can, in Sanitize() | 14:18 |
| niemeyer | zyga: That's not what jdstrand asked | 14:19 |
| niemeyer | zyga: He asked whether it was possible.. yes, it's possible | 14:19 |
| jdstrand | cause in the case of unity, version 7 is 'unsafe' and version 8 is 'safe' (whatever safe/unsafe ends up meaning in terms of store/snappy/etc notwithstanding) | 14:19 |
| jdstrand | just mentioning that as something to think about with this sort of thing | 14:19 |
| jdstrand | ok, I don't mean to distract. thanks! :) | 14:20 |
| niemeyer | jdstrand: Right.. I think for the scenario we have at hand, your proposal is the easiest/cleanest | 14:20 |
| jdstrand | cool | 14:20 |
| niemeyer | jdstrand: the unity7 interface will likely just die a cold death | 14:20 |
| jdstrand | hehe | 14:20 |
| niemeyer | jdstrand: and "unity" will rule without all that extra complexity | 14:21 |
| jdstrand | sounds great | 14:21 |
| niemeyer | jdstrand: For your point (1) above, note that global interfaces are defined at the top level | 14:21 |
| niemeyer | jdstrand: Without any per-app mentions | 14:21 |
| jdstrand | sure | 14:21 |
| niemeyer | jdstrand: to be clear, by global I mean "for all apps" | 14:21 |
| jdstrand | you can do global plugs that are for all, or you can do per-app plugs | 14:22 |
| niemeyer | Yeah | 14:22 |
| jdstrand | I was mainly trying to get if you are doing per-app, you don't need the global if you are doing all defaults | 14:22 |
| niemeyer | zyga, jdstrand: Question about the template clean up that is on the queue for review: | 14:22 |
| niemeyer | +// TODO: use modern variables when default template is compatible | 14:23 |
| niemeyer | +// with them and the custom template is not used. | 14:23 |
| zyga | yes? | 14:23 |
| niemeyer | zyga, jdstrand: What's left to do about this? | 14:23 |
| jdstrand | just have INSTALL_DIR | 14:23 |
| jdstrand | remove the others for a future commit | 14:23 |
| jdstrand | the idea is, those new variables should happen in the same commit as the policy changes | 14:23 |
| niemeyer | jdstrand: Can you jump in with that? | 14:24 |
| zyga | niemeyer: from my POV we need to patch the default template to use less variables (I"ll let jdstrand pick which) and commit this in one change as he just said | 14:24 |
| jdstrand | sure | 14:24 |
| zyga | niemeyer: then for legacy (old-security) we're covered - we can still use legacy variables and for all other cases we have a clean definition of what the policy depends on | 14:25 |
| jdstrand | I'd like to wait until after we are using the interfaces code for generation and enforcement though | 14:25 |
| jdstrand | ie, lets get all the interfaces and glue landed so it is doing stuff | 14:25 |
| niemeyer | jdstrand: Sounds good | 14:26 |
| jdstrand | then I can tweak the policy, etc | 14:26 |
| niemeyer | jdstrand: Will add a card for that, thanks! | 14:26 |
| jdstrand | I have a small queue of minor other updates. I'll add this to my list | 14:26 |
| jdstrand | niemeyer: thanks! please assign it to me | 14:26 |
| niemeyer | jdstrand: Will do, thank you | 14:28 |
| jdstrand | zyga (and niemeyer): and to be clear about the launcher. I've got a number of things I'm working on: seccomp argument filtering, adding @complain, adding @deny, and fixing the cgroups issue on 16.04 we talked about earlier (LP: #1564401) | 14:31 |
| ubottu | Launchpad bug 1564401 in ubuntu-core-launcher (Ubuntu) "launcher does not apply cgroups on 16.04" [High,Triaged] https://launchpad.net/bugs/1564401 | 14:31 |
| jdstrand | I have time to do these things, so you don't have to worry about them | 14:31 |
| niemeyer | jdstrand: Thanks, certainly a relief | 14:31 |
| niemeyer | zyga: #759 is ready for your attention again | 14:32 |
| jdstrand | I even have a branch for arg filtering. that'll be a nice feature | 14:32 |
| zyga | thanks, looking | 14:32 |
| jdstrand | niemeyer: I also wanted you to know that I implemented and landed a change to the launcher that creates a devpts newinstance. I closed a card in some snappy trello board, but I feel like it might not be the board you are currently using | 14:33 |
| jdstrand | niemeyer: regardless, that closed a hole in the confinement story that I really wanted addressed in 16.04 | 14:34 |
| jdstrand | niemeyer: just fyi for awareness | 14:34 |
| niemeyer | jdstrand: Ah, nice! | 14:35 |
| zyga | niemeyer: replied, have a look and tell me what to do about } issue | 14:35 |
| jdstrand | morphis_: hey, I think the meeting you sceduled is premature | 14:36 |
| niemeyer | zyga: I don't get the comment.. can you please expand on why that's not appropriate? Starter for the conversation: the template has a curly brace in it, why are we taking it off? | 14:36 |
| jdstrand | scheduled | 14:36 |
| niemeyer | jdstrand: Your observation/input on that one would be welcome ^ | 14:36 |
| jdstrand | morphis_: I just had a meeting with jhodapp yesterday explaining things. and mentioned those things to kgunn, and awe, etc | 14:37 |
| zyga | niemeyer: we take it off because this function returns the header of the full policy, then we inject any number of snippets and then the terminating } | 14:37 |
| niemeyer | zyga: We take it off because we inject it again, yes.. why do we do that? | 14:37 |
| zyga | niemeyer: to not remove } we'd have to know where to insert the snippets somehow | 14:37 |
| zyga | niemeyer: the snippets have to be "in the middle" of the { } | 14:37 |
| zyga | niemeyer: and there is no ### marker for where that is currently | 14:38 |
| jdstrand | morphis_: can you sync up with jhodapp-- he has the whole story. the summary is: we can't do anything with bluez, nm, pulse, mir, etc until the interfaces/state engine stuff lands. it is close to landing (days). when it lands zyga and I will come knocking | 14:38 |
| niemeyer | zyga: If only we had a variable system to do that.. :) | 14:38 |
| zyga | niemeyer: yes but remember that this has to stay compatible with 3rd party templates | 14:38 |
| jdstrand | I wanted to ask about that | 14:39 |
| morphis_ | jdstrand: did already sync with him, just wanted a pre-check so see if what we will get satisfies already the different bits we need | 14:39 |
| zyga | niemeyer: I can easily define ###SNIPPETS### and replace it with the actual snippets. Then we don't have to parse the template in any way but then if anyone ships a custom policy it has to include that section. | 14:39 |
| jdstrand | why are we supporting 3rd party templates? I thought we said that old-security/security-template was going away? | 14:39 |
| zyga | niemeyer: and since we wanted to stay compatible with 15.04, I didn't do that by default | 14:40 |
| morphis_ | jdstrand: more technically sided talking, but fine if you don't have time, I think zyga can fill us in as well | 14:40 |
| jdstrand | morphis_: it wasn't so much about time as the timing | 14:40 |
| jdstrand | morphis_: if zyga thinks the timing is ok, that's fine (but note, the dbus bits are only under review right now) | 14:41 |
| zyga | niemeyer: given the interfaces that are coming, is old-security something that will look relevant for 16.04? | 14:41 |
| morphis_ | jdstrand: I know that we're close to land this, but we still don't know what we really get when this lands, so just wanted to get an early heads up | 14:41 |
| niemeyer | zyga: I'm not sure, to be honest.. perhaps we should close that down so we don't need to support that forever | 14:41 |
| niemeyer | zyga: With the mechanism we have in place we can quickly cook new interfaces that support old logic | 14:42 |
| niemeyer | jdstrand: What's your opinion on that one? | 14:42 |
| jdstrand | zyga: in the meeting we had last month between you me and niemeyer we decided that old-security/security-override and old-security/security-policy must stay. old-security/caps and old-security/security-template could stay, but to use the interfaces code | 14:42 |
| zyga | niemeyer: I think that doing ###SNIPPETS### as a mandatory thing is a quick and easy solution and is quite clearner than parsing the template | 14:42 |
| jdstrand | zyga: as in, 'caps' just maps internally to plug the right thing and so does security-template. we don't read ubuntu-core-security files any more | 14:43 |
| zyga | jdstrand: hmm, so we don't need custom apparmor policy in any way? | 14:43 |
| zyga | jdstrand: (sorry not policy) custom base template? | 14:43 |
| zyga | (woring is confusing sometimes) | 14:43 |
| niemeyer | jdstrand: Right, but that implies having to parse third-party templates, which was zyga's point which you seemed to object about | 14:43 |
| jdstrand | you misunderstand | 14:43 |
| jdstrand | there are 4 directives: | 14:43 |
| niemeyer | (I misunderstand too, I'm sure) | 14:44 |
| jdstrand | old-security/caps: )possibly) support but with internal map to plugs | 14:44 |
| jdstrand | old-security/security-template: (possibly) support but always use defaultTemplate | 14:44 |
| jdstrand | old-security/security-override: support and adds to snippets | 14:44 |
| jdstrand | old-security/security-policy: support for hand-crafted security policy | 14:45 |
| zyga | ah | 14:45 |
| zyga | yes, I misunderstood difference between template and policy | 14:45 |
| jdstrand | the first two use ubuntu-core-security policy | 14:45 |
| jdstrand | lets just get rid of old-security/security-template because we decided we don't want an unconfined template and that leaves only the default template | 14:46 |
| jdstrand | it is your choice to keep old-security/caps, but if you keep it, map it to plugs under the hood. don't parse template policy groups from ubuntu-core-security | 14:46 |
| niemeyer | jdstrand: What's the meaning of security-template again? I misunderstand what it would mean to support it but force defaultTemplate usage (seems contradictory, so I probably misunderstand their meaning) | 14:47 |
| * zyga feels the same, | 14:47 | |
| jdstrand | old-security/security-policy would completely skip defaultTemplate. it probably needs support for snippets for interface grants | 14:47 |
| zyga | we either respect the template given or we use default template | 14:47 |
| jdstrand | niemeyer: in 15.04 you could specify a template from ubuntu-core-security | 14:47 |
| jdstrand | let me back up | 14:47 |
| jdstrand | in 15.04 policy was generated by picking a template and adding caps to it | 14:48 |
| jdstrand | security-template was used to specify the template and caps was use to specify the caps | 14:48 |
| jdstrand | in 16.04, policy is generated by adding interfaces to defaultTemplate | 14:49 |
| jdstrand | so just make security-template go away | 14:49 |
| jdstrand | in 15.04 there werre only two templates: default and unconfined | 14:49 |
| niemeyer | Aha! | 14:49 |
| jdstrand | unconfined was rarely used cause, well, it was unconfined and triggered manual review | 14:50 |
| jdstrand | and we decided last month that if someone actually wanted unconfined in 16.04, they would use old-security/security-policy to handcraft a lenient policy (and also triggers manual review) | 14:50 |
| zyga | I think I understand now | 14:51 |
| niemeyer | jdstrand: and why did we ever feel the need to have security-policy? | 14:51 |
| jdstrand | so there is no reason at all to support old-security/security-template in 16.04 | 14:51 |
| niemeyer | jdstrand: (vs. an override) | 14:51 |
| jdstrand | niemeyer: old-security/security-override is not rich. it is easy to use. it is 'add this syscall' and 'add this file for reading' | 14:51 |
| elopio | kyrofa: https://spi.canonical.com/assets/api-reference.html | 14:52 |
| jdstrand | nessita: old-security/security-policy is raw security policy-- full apparmor, full list of seccomp. no templated policy | 14:52 |
| jdstrand | niemeyer: ^ | 14:52 |
| jdstrand | nessita: sorry, nm | 14:52 |
| niemeyer | jdstrand: Hmm | 14:52 |
| elopio | kyrofa: and here are my notes for setting it up for ubuntu-core: http://pad.ubuntu.com/spi | 14:53 |
| niemeyer | jdstrand: Okay.. thanks a lot.. have much better context now | 14:53 |
| jdstrand | niemeyer: old-security/security-policy going forward is our escape hatch for when something must be done fast and interfaces aren't in place for it yet | 14:53 |
| jdstrand | niemeyer: it will always trigger a manual review in the store and is not intended for normal use | 14:53 |
| niemeyer | jdstrand: It's a dangerous one too | 14:53 |
| jdstrand | oh yes | 14:53 |
| niemeyer | jdstrand: Not in the sense you're thinking, though :) | 14:54 |
| jdstrand | incredibly | 14:54 |
| niemeyer | jdstrand: I mean it's dangerous because it's a cheap short cut for an otherwise well designed system | 14:54 |
| jdstrand | niemeyer: well, yes, but time constraints... | 14:54 |
| niemeyer | jdstrand: Well, exactly | 14:54 |
| vila | elopio: https://github.com/ubuntu-core/snapcraft/pull/414 failed the example tests again, not sure I understand what is going on there, can you help ? | 14:54 |
| jdstrand | niemeyer: but the plan is always to use interfaces and not that | 14:55 |
| niemeyer | jdstrand: Why am I not trusting that too much? :) | 14:55 |
| niemeyer | jdstrand: Time constraints win | 14:55 |
| elopio | vila: it says: connection timed out. So the testbed died somehow. It's running again. | 14:55 |
| jdstrand | niemeyer: I endup seeing all of the security manual reviews in the store for touch and snappy | 14:55 |
| zyga | niemeyer: I think I will agree with you on this, the moment someone learns how to use old-security, there is no incentive to look at interfaces further | 14:55 |
| zyga | "just use sudo" | 14:55 |
| zyga | aka, old -secuirty | 14:55 |
| jdstrand | niemeyer: they are exceedingly rare because the developer is blocked-- the upload doesn't go through. I say no a lot, etc | 14:55 |
| jdstrand | so I wouldn't get hung up on developers just choosing it | 14:56 |
| niemeyer | jdstrand: What if we instead tried to go without it? | 14:56 |
| jdstrand | the store doesn't let them and I am very strict | 14:56 |
| niemeyer | jdstrand: We can always put it back in | 14:56 |
| niemeyer | jdstrand: It'll be very hard to remove it later | 14:56 |
| jdstrand | niemeyer: I don't think it will be hard to remove in 17 | 14:57 |
| jdstrand | it would of course be hard to remove from 16 | 14:57 |
| zyga | I think that once the developer mode is in place we can give developers enough tools to do self-provisioning to the point where they can ask us to implement a proper interface | 14:57 |
| jdstrand | but we discussed this last month | 14:57 |
| jdstrand | I promise you that we'll need it for something | 14:57 |
| niemeyer | jdstrand: Yeah, I know we discussed this | 14:57 |
| jdstrand | someone will need an app for a demo tomorrow that will blow a sales call | 14:57 |
| jdstrand | and the interfaces don't support it, etc | 14:58 |
| niemeyer | jdstrand: developer mode.. | 14:58 |
| vila | elopio: thanks ! | 14:58 |
| jdstrand | as the one who always gets that call, I am very uncomfortable taking it out | 14:58 |
| vila | elopio: Is re-running something I could have done ? | 14:58 |
| zyga | (even if we don't give advice, just turn off process killing, developer mode sounds like the universal way out) | 14:59 |
| jdstrand | niemeyer: sure, but someone will want to demo an app without having to go into that | 14:59 |
| niemeyer | jdstrand: Well, to me this is a good reason for us to not have it | 14:59 |
| niemeyer | jdstrand: Precisely because once we have the mechanism, people with bigger guns will be constantly forcing hacks in | 14:59 |
| elopio | vila: only if you are in the whitelist. But we need to get more resources before we add people to the whitelist. fgimenez is on that. | 15:00 |
| jdstrand | I mean we can take it out-- but when security blocks them and there is no escape hatch for the demo or for the client for a must have thingamajig, can I forward them to you? :) | 15:00 |
| vila | elopio: nm then | 15:00 |
| niemeyer | jdstrand: Yes! | 15:00 |
| zyga | we'll setup a FAQ that says: $ snap enable developer-mode (or similar) | 15:00 |
| jdstrand | one could make the same argument for security override then | 15:00 |
| niemeyer | jdstrand: Yep | 15:00 |
| niemeyer | jdstrand: My goal is to have quick turnarounds for real interfaces | 15:01 |
| jdstrand | ok. don't say I didn't warn you :) | 15:01 |
| zyga | niemeyer: hmm, so are you inclined to kill old-security right here, right now | 15:01 |
| code1o6 | ls | 15:01 |
| niemeyer | jdstrand: I want to establish a process for us to release meaningful improvements every other week | 15:01 |
| ogra_ | no such file or directory | 15:01 |
| jdstrand | niemeyer: sure. I think some interfaces will be fast. some will not. I think over time, hopefully they'll get faster and faster | 15:01 |
| vila | ogra_: ha, thanks, exactly the bit I was missing from the error message | 15:02 |
| niemeyer | zyga: Yes.. just thinking about the best way to do that | 15:02 |
| niemeyer | zyga: Definitely before 16.04 | 15:02 |
| jdstrand | cause we'll have seen more and more exceptional cases, etc | 15:02 |
| * ogra_ hugs vila ... happy to help :) | 15:02 | |
| zyga | niemeyer: is there a spec on how to enable / disable developer mode for a given snap? | 15:02 |
| niemeyer | jdstrand: Right, agreed | 15:02 |
| niemeyer | jdstrand: As a rule of thumb, I'd prefer to release a half-baked interface that is under the entire control of the security team, than a security policy that is hand coded | 15:03 |
| niemeyer | jdstrand: hand-coded security policies break the whole system organization | 15:03 |
| niemeyer | zyga: snap install ---devel, or similar | 15:04 |
| vila | joke aside, I just did 'snapcraft upload wrong-filename' and the output was: 'wrong-filename' and nothing else. --debug told me it was FIleNotFound but I found --debug while already under pdb ;) | 15:04 |
| zyga | niemeyer: I'll see if I can patch that in | 15:04 |
| vila | ogra_: not sure how you knew that... ;) | 15:04 |
| ogra_ | intuition :) | 15:04 |
| jdstrand | niemeyer: I agree. I will mention that the security team would review the hand-crafted policy (or flat refuse to accept it) | 15:04 |
| niemeyer | jdstrand: I reckon, but it's still a different relationship | 15:05 |
| niemeyer | jdstrand: It's something the security team can review, have an opinion about, and change | 15:05 |
| niemeyer | jdstrand: vs. something lost inside a snap | 15:05 |
| jdstrand | niemeyer: but anyhoo. to be clear, obviously the security team will take part in interface security policy, but the snappy team will be there for approval to add/design/non-security policy changes/etc, correct? | 15:05 |
| jdstrand | niemeyer: ie, no interface will go through without collaborating? | 15:06 |
| zyga | jdstrand: well, that would be hard to sneak in | 15:06 |
| jdstrand | I'm not talking about a malicious actor | 15:06 |
| niemeyer | jdstrand: Of course | 15:06 |
| zyga | jdstrand: even non-malicious | 15:06 |
| jdstrand | niemeyer: perfect | 15:06 |
| niemeyer | jdstrand, zyga: So I think the easiest is to flip the switch when the new security logic is used | 15:07 |
| jdstrand | zyga: I'm just getting at defining the process that if an interface is added by snappy core, there is (at least) security team ack and vice versa | 15:07 |
| zyga | jdstrand: yes, I think we need to have a clearly documented process to create or alter interfaces | 15:08 |
| jdstrand | niemeyer: my hope is that security-override will be needed less with seccomp arg filtering | 15:08 |
| niemeyer | zyga: In other words, once the InterfaceManager goes live, old-security is obsoleted and starts to refuse installs | 15:08 |
| zyga | niemeyer: woot, that's nice | 15:08 |
| zyga | niemeyer: and simplifies many issues that were special cased | 15:08 |
| jdstrand | cause we can add a few things that people get blocked on currently, but in a controlled way | 15:08 |
| jdstrand | eg, setpriority | 15:08 |
| jdstrand | kyrofa: ^ | 15:08 |
| jdstrand | :) | 15:08 |
| niemeyer | jdstrand: Right, exactly | 15:09 |
| zyga | niemeyer: I'll make that happen, and I know have the answer to } | 15:09 |
| kyrofa | jdstrand, haha, your memory is scary | 15:09 |
| niemeyer | zyga: +1 | 15:09 |
| zyga | niemeyer: is there a card for $ snap install --devel | 15:09 |
| jdstrand | and I people are using security-override today mostly to work around seccomp policy. occasionally for an apparmor read or write here and there | 15:09 |
| zyga | sergiusens: ^^ (old-security is dead) | 15:10 |
| niemeyer | sergiusens: s/dead/dying/ | 15:10 |
| niemeyer | zyga: ^ | 15:10 |
| zyga | niemeyer: sure, I'll be hard at work to kill it entirely :) | 15:10 |
| jdstrand | kyrofa: in fact, this is in my test in my branch: 'setpriority - 0 >=0' | 15:11 |
| niemeyer | jdstrand: Right, there you go.. there are likely patterns already being established via the use of overrides which would be trivial to have an interface for | 15:11 |
| niemeyer | jdstrand: But because it's so cheap, we never cooked it | 15:11 |
| * zyga has some cool ideas | 15:11 | |
| jdstrand | niemeyer: well, note, there may be a pattern, but it is only for like 3 things :) | 15:11 |
| kyrofa | jdstrand, nice :) | 15:11 |
| zyga | but I'll let those wait for next week when it all works | 15:11 |
| jdstrand | niemeyer: ie, people hate using these cause the upload gets hung up, but I mentioned that already | 15:12 |
| niemeyer | jdstrand: It's okay.. migth be even just one thing to be clear.. we want to have people covered anyway | 15:12 |
| jdstrand | so yeah, I'm fine with removing it. if developer mode is working right, that is the escape hatch. if someone complains and complains, I'll redirect to 'the decider' :) | 15:13 |
| === chihchun is now known as chihchun_afk | ||
| jdstrand | tyhicks: hey, so heads up on my queue of launcher changes: 1. sarnold's review fixes (MP awaiting review), 2. preprocessor review (will request MP this morning), 3. seccomp arg filtering (will be requesting MP soon), 4. support @deny rules (in progress), 5. support @complain mode (not started), 6. fix bug #1564401 (not started, likely start after preprocessor) | 15:22 |
| ubottu | bug 1564401 in ubuntu-core-launcher (Ubuntu) "launcher does not apply cgroups on 16.04" [High,Triaged] https://launchpad.net/bugs/1564401 | 15:22 |
| beuno | pedronis, niemeyer, matiasb_, invite sent for our call! | 15:22 |
| === matiasb_ is now known as matiasb | ||
| jdstrand | tyhicks: 2-6 depend on '1'. 4 and 5 depend on 2 | 15:23 |
| matiasb | ack | 15:23 |
| jdstrand | tyhicks: I'd really like '1' to get reviewed soon (ideally today), but please advise on how to proceed | 15:24 |
| jdstrand | tyhicks: I guess the review fixes aren't required for today, but I'd like to talk through the timing of these things | 15:27 |
| wililupy | In my kernel snap, I have pre-built modules, if I use the copy plugin to install them to /lib/modules/`uname -r`/kernel/drivers/net/ethernet/igb and so on, does that have to happen before I run the kbuild and build my kernel? | 15:31 |
| ogra_ | wililupy, i would think so since you want them to be picked up by the depmod run that the kernel build does | 15:32 |
| ogra_ | else modprobe wont know about them | 15:32 |
| wililupy | Thats what lool was saying, so will the copy plugin also create the uname -r directory I need? | 15:32 |
| wililupy | ogra_: ^^ | 15:33 |
| wililupy | My snapcraft.yaml: https://pastebin.canonical.com/153091/ | 15:33 |
| ogra_ | hmm, no idea, thats a sergiusens question | 15:34 |
| ogra_ | 456793 | 15:46 |
| lool | wililupy: checkout snapcraft/plugins/kernel.py in snapcraft | 15:49 |
| lool | wililupy: it basically copies modules deps files directly | 15:49 |
| lool | so can't use this plugin to compute new deps | 15:49 |
| ogra_ | oh, the kernel build process doesnt run depmod at the target dir ? | 15:50 |
| lool | wililupy: you could extend the plugin or do some postprocessing, or use kbuild to rebuild the kernel (not sure how this will play with module deps either) | 15:50 |
| lool | ogra_: there are two kernel plugins; I believe wililupy was trying to use a kernel .deb so the kernel plugin | 15:50 |
| ogra_ | we have a kernel plugin using debs ? | 15:50 |
| wililupy | lool: I was going to use kbuild to build the kernel | 15:51 |
| lool | now the kbuild module does basically a make install; I dont know if it would pickup third party vendor directories in the deps, it's possible | 15:51 |
| lool | but in any case, you would need these to be installed before the kbuild plugin builds | 15:51 |
| tyhicks | jdstrand: I'll do the review for #1 now | 15:51 |
| * wililupy wonders if I put them in the right location in staging if that will work? | 15:52 | |
| jdstrand | tyhicks: well, I didn't mean for you to stop what you were doing (I mean it's fine if you want to review) | 15:52 |
| jdstrand | tyhicks: I just wanted you to be aware of the queue and if you had opinions on how we should time the reviews, etc | 15:53 |
| tyhicks | jdstrand: you've been waiting for a while and I don't want to pull sarnold off of MIRs so it falls in my lap | 15:53 |
| tyhicks | jdstrand: it isn't a problem :) | 15:53 |
| tyhicks | I'm in between things anyways | 15:54 |
| jdstrand | ok, thanks | 15:54 |
| zyga | jdstrand, niemeyer: ###SNIPPETS### https://github.com/ubuntu-core/snappy/pull/759/files | 15:57 |
| kyrofa | wililupy, let me try to help | 15:58 |
| wililupy | thank you kyrofa | 15:59 |
| kyrofa | wililupy, so you have pre-built modules that your kernel requires? | 15:59 |
| wililupy | yes. I built them against the kernel I will be using in snappy. | 16:00 |
| sergiusens | zyga, niemeyer jdstrand can we sync after a call I have now? If not a snapcraft bug to keep track or anything would be welcome | 16:01 |
| sergiusens | d | 16:01 |
| zyga | sergiusens: we can file the bug on old-security when it is about to happen | 16:01 |
| niemeyer | sergiusens: Happy to sync | 16:01 |
| jdstrand | I also need to update the review tools | 16:01 |
| sergiusens | zyga, thanks | 16:01 |
| niemeyer | sergiusens: Let me know when you're available | 16:01 |
| sergiusens | sync can just be, tell me what do do ;-) | 16:02 |
| kyrofa | wililupy, why not ship them in the kernel itself? | 16:02 |
| kyrofa | wililupy, closed-source stuff? | 16:02 |
| wililupy | kyrofa, thats not a bad idea. It is closed source, so I can't put it upstream, but I can do it in my build environment. | 16:02 |
| kyrofa | wililupy, right | 16:03 |
| wililupy | what if my module has the same name as a current driver in the kernel, ie igb? | 16:19 |
| kyrofa | wililupy, ah, which comes back to the depmod stuff I see above | 16:22 |
| niemeyer | sergiusens: We're dropping old-security before 16.04.. that's the core of it | 16:32 |
| niemeyer | sergiusens: It's there for the time being, so no immediate action needed | 16:32 |
| niemeyer | sergiusens: Once the new security infra goes live, we'll kill old-security with it and reject snaps that attempt to be installed with it | 16:32 |
| niemeyer | sergiusens: This should happen over the next week.. we'll ping you before released | 16:32 |
| niemeyer | jdstrand: There's a note on https://github.com/ubuntu-core/snappy/pull/759/files which says // XXX: This needs to be verified by security team. | 16:33 |
| niemeyer | jdstrand: It looks straightforward to me.. can you please +/-1 it so we can drop the note? | 16:33 |
| sergiusens | niemeyer, ok, will we have replacements for what is currently done in old security for our examples or will they just not work at all? | 16:34 |
| kyrofa | wililupy, at least on my ubuntu machine my /etc/depmod.d directory has a conf file containing "search updates ubuntu built-in" | 16:35 |
| kyrofa | wililupy, assuming I understand that correctly (big assumption) one could get away with placing newer modules in the updates directory under modules | 16:36 |
| wililupy | This is an interresting error: Issues while validating snapcraft.yaml: mapping values are not allowed here on line 19 of snapcraft.yaml | 16:37 |
| zyga | jdstrand: is https://github.com/ubuntu-core/snappy/pull/759/files#diff-57dc34ab6f4bf9730b356d0439daa0fdR123 okay? | 16:37 |
| zyga | (attach_disconnected,complain) | 16:38 |
| kyrofa | wililupy, same YAML you pasted earlier? | 16:38 |
| wililupy | kyrofa yes | 16:38 |
| kyrofa | wililupy, the syntax looks okay, so try quoting the strings | 16:38 |
| niemeyer | sergiusens: We have several of the old school profiles migrated already | 16:39 |
| niemeyer | sergiusens: to first class interfaces | 16:39 |
| niemeyer | sergiusens: https://github.com/ubuntu-core/snappy/tree/master/interfaces/builtin | 16:40 |
| sergiusens | niemeyer, thanks for the link! this will help a lot :-) | 16:42 |
| wililupy | kyrofa, sorry, that is my old snapcraft.yaml. Here is the current one I am using: https://pastebin.canonical.com/153114/ | 16:42 |
| kyrofa | wililupy, try not nesting the kconfigs in like that | 16:44 |
| kyrofa | wililupy, the key `kconfigs` I mean | 16:44 |
| wililupy | kyrofa, wow, it was that picky... lol | 16:46 |
| kyrofa | wililupy, it's yaml | 16:46 |
| wililupy | Here's an interresting error: Pulling kernel 'NoneType' object has no attribute 'headers' | 16:50 |
| kyrofa | wililupy, run with the --debug flag | 16:56 |
| wililupy | kyrofa: http://pastebin.canonical.com/153118 | 17:00 |
| kyrofa | wililupy, ah, https://bugs.launchpad.net/snapcraft/+bug/1560553 | 17:01 |
| ubottu | Launchpad bug 1560553 in Snapcraft "snapcraft error message is not very helpful when using storeapi without being logged in" [Medium,Fix committed] | 17:01 |
| kyrofa | wililupy, you need to be authenticated to download the OS snap, so run `snapcraft login` first | 17:01 |
| wililupy | kyrofa, thank you. May need to update the documentation so that others don't hit this easy mistake in the future... ;) | 17:04 |
| kyrofa | wililupy, yeah that bug has been fixed, just not released | 17:04 |
| jdstrand | zyga: yes | 17:04 |
| zyga | jdstrand: perfect, thanks | 17:04 |
| kyrofa | sergiusens, can you remind me why we need to be logged in at all to download that snap? No more anonymous snap downloads? | 17:05 |
| jdstrand | zyga: though at line 138 aren't you undoing that change? | 17:06 |
| zyga | jdstrand: hmm let's see | 17:06 |
| wililupy | Building kernel!! See how long this takes. Time for lunch. Thanks kyrofa | 17:06 |
| sergiusens | kyrofa, because that is going away | 17:06 |
| kyrofa | sergiusens, ah, okay | 17:06 |
| kyrofa | wililupy, no problem :) | 17:06 |
| jdstrand | zyga: oh, no, I think its ok | 17:07 |
| zyga | jdstrand: I don't see how | 17:07 |
| zyga | jdstrand: that part is not a ### ... ### so we don't change it | 17:07 |
| zyga | (in retrospective, we should) | 17:07 |
| jdstrand | zyga: yeah, my mistake | 17:07 |
| sergiusens | wililupy, there is no documentation for the kernel snap though, it is in experimental mode; once the core supports multiple initrds this download phase will go away | 17:07 |
| wililupy | Got it. Thanks sergiusens | 17:08 |
| niemeyer | zyga: So let's please drop the comment there | 17:09 |
| zyga | niemeyer: gladly | 17:09 |
| niemeyer | zyga, jdstrand: and I think it's ready to go in? | 17:09 |
| zyga | niemeyer: removed now | 17:10 |
| zyga | niemeyer: yes, I think so too :) | 17:10 |
| zyga | niemeyer: I'll post some follow-up patches, one thing that's still a TODO is to remove cache elements but I have this written down and I'd like to first make use of this in snap install | 17:11 |
| jdstrand | boy, took me a minute to wrap my head around the func(placehlder []... bits | 17:11 |
| zyga | ok | 17:11 |
| jdstrand | I think it's ready | 17:14 |
| code1o6 | guys is there any steps prior to running snappy login? | 17:15 |
| niemeyer | zyga: Cool | 17:15 |
| code1o6 | *snapcraft login | 17:17 |
| zyga | niemeyer: shall we merge with one +1 | 17:17 |
| code1o6 | snapcraft: error: argument cmd: invalid choice: 'login' | 17:17 |
| zyga | niemeyer: (we could count jdstrand's as a +1 though :-) | 17:17 |
| code1o6 | sergiusens, any ideas ^^? | 17:18 |
| jdstrand | I didn't really do a go code review | 17:19 |
| sergiusens | code1o6, snapcraft --version ? | 17:19 |
| jdstrand | zyga, niemeyer: so, looking at this dbus PR I'm reminded that 'Type=dbus' dbus needs to be added to the systemd service file. is that handled properly with this new work or are we expecting the dev to set 'daemon: dbus' in their yaml? | 17:23 |
| zyga | jdstrand: hmmmm, I'm not sure | 17:23 |
| zyga | jdstrand: so does that mean that service file depends on interfaces? | 17:24 |
| zyga | jdstrand: (the contents of the service file may needs to change when dbus is in use?) | 17:24 |
| jdstrand | zyga: for a service that plugs a dbus bus policy interface, systemd won't start the service correctly without Type=dbus in the service file, no | 17:25 |
| jdstrand | ie, bluez needs bluez bus policy | 17:25 |
| jdstrand | it won't start correctly without Tyle=dbus | 17:25 |
| jdstrand | Type=dbus | 17:25 |
| jdstrand | but, we could say for the moment the dev needs to do: | 17:26 |
| jdstrand | apps: | 17:26 |
| jdstrand | bluez: | 17:26 |
| jdstrand | plugs: [bluez5] | 17:26 |
| jdstrand | daemon: dbus | 17:26 |
| jdstrand | and avoid magic | 17:26 |
| zyga | niemeyer: ^^ opinions | 17:26 |
| zyga | jdstrand: I like that much better | 17:26 |
| * niemeyer reads | 17:27 | |
| zyga | jdstrand: I don't like the hidden magic dependency | 17:27 |
| jdstrand | the review tools could try to help their too | 17:27 |
| jdstrand | there* | 17:27 |
| jdstrand | ie, they could know that bluez5 needs daemon: dbus | 17:27 |
| niemeyer | jdstrand: What's the real effect of having Type: dbus in systemd? | 17:28 |
| niemeyer | jdstrand: e.g. how will systemd know when to start the service? | 17:28 |
| jdstrand | "Behavior of dbus is similar to simple; however, it is expected that the daemon acquires a name on the D-Bus bus, as configured by BusName=. systemd will proceed with starting follow-up units after the D-Bus bus name has been acquired. Service units with this option configured implicitly gain dependencies on the dbus.socket unit. This type is the default if BusName= is specified." | 17:29 |
| jdstrand | https://www.freedesktop.org/software/systemd/man/systemd.service.html | 17:29 |
| jdstrand | right, the service file also needs BusName | 17:29 |
| jdstrand | hrmm, that means the service file generation does need to interact with interface | 17:30 |
| jdstrand | interfaces* | 17:30 |
| niemeyer | jdstrand: Yeah, that's what I was wondering.. it needs information about what is being listened on | 17:31 |
| niemeyer | jdstrand: Note that it's also a slot above, not a plug | 17:31 |
| jdstrand | no, this is a plug | 17:31 |
| niemeyer | ? | 17:31 |
| jdstrand | this isn't what bluez provides to clients, this is what bluez needs itself | 17:31 |
| niemeyer | jdstrand: It doesn't make sense to me | 17:32 |
| zyga | jdstrand: that's still a slot | 17:32 |
| zyga | jdstrand: (think where plugs go to) | 17:32 |
| niemeyer | jdstrand: bluez is consuming bluez? | 17:32 |
| jdstrand | yes | 17:32 |
| zyga | hmm? | 17:32 |
| niemeyer | jdstrand: This seems a bit off | 17:32 |
| jdstrand | I mean, it could be a different name | 17:32 |
| jdstrand | ok let's back up | 17:32 |
| zyga | jdstrand: I though that this is what permanent snippet on bluez slot would do | 17:32 |
| jdstrand | the system needs to provide an interface (slot) that the bluez dbus service can use to run at all | 17:33 |
| jdstrand | bluez provides a slot that clients can use to talk to bluez | 17:33 |
| jdstrand | my plug referred to the former | 17:33 |
| niemeyer | jdstrand: That's similar to the cases we discussed for x11 and mir | 17:33 |
| zyga | jdstrand: what does the system need to provide and how is this different from what we managed to simplify with mir? | 17:33 |
| jdstrand | we didn't simplify anything with mir | 17:34 |
| niemeyer | jdstrand: We actually did, I think | 17:34 |
| zyga | jdstrand: we replaced two interfaces with one | 17:34 |
| zyga | jdstrand: no mir-server, mir-client; there's just a mir interface | 17:34 |
| jdstrand | we haven't been able to explore any of these yet cause it is blocked on what you are trying to land | 17:34 |
| zyga | jdstrand: and mir interface slot grants rights that would be granted by mir-server | 17:34 |
| jdstrand | oh, maybe I am confused | 17:34 |
| jdstrand | ok, regardless | 17:34 |
| niemeyer | jdstrand: This feature is already in place in the interface system you're currently committing to | 17:35 |
| jdstrand | if something is using a dbus interface in this manner, the service file needs Type=dbus and BusName=<something from the interface> | 17:35 |
| niemeyer | jdstrand: As an interesting side note, we also need to restrict who offers those slots at all | 17:35 |
| niemeyer | jdstrand: As offering the slot implies having access to resources already | 17:35 |
| zyga | niemeyer: good point, it's also more iffy since there's no snap id yet | 17:35 |
| niemeyer | zyga: The joys of implementing a non-trivial system under time pressure | 17:36 |
| zyga | :-) | 17:36 |
| jdstrand | that's fine. my head isn't totally wrapped around all that yet cause I haven't played with these things yet | 17:36 |
| zyga | jdstrand: is it correct to assume that a snap may have many .service files? | 17:36 |
| zyga | jdstrand: and it may need many bus names? | 17:36 |
| zyga | jdstrand: so this is an app-level property | 17:36 |
| jdstrand | zyga: I would think any entry under apps could potentially be a separate dbus service, yet | 17:37 |
| jdstrand | yes | 17:37 |
| niemeyer | jdstrand: Will that systemd auto-start feature work when there are multiple bus names involved? It should, right? | 17:37 |
| jdstrand | eg, a thick snap that provides ofono and nm | 17:37 |
| zyga | right, so this is something that's aligned with what we have now; | 17:37 |
| jdstrand | niemeyer: each is a different service file that is snap_app....service so yeah it should all be fine | 17:38 |
| niemeyer | jdstrand: Don't think I get it.. | 17:38 |
| jdstrand | though, that assumes ordering of dbus services within the snap doesn't matter | 17:39 |
| niemeyer | jdstrand: Question was what if one app provides multiple dbus services.. same process, multiple services | 17:39 |
| jdstrand | niemeyer: perhaps I didn't understand your question | 17:39 |
| zyga | hmmm | 17:39 |
| jdstrand | that is unusual | 17:39 |
| niemeyer | jdstrand: Per systemd documentation, BusName can apparently only be a single bus name | 17:39 |
| niemeyer | jdstrand: But that's not a constraint on the dbus system | 17:39 |
| jdstrand | you'd have to fork separate threads that each bind to a separate name | 17:39 |
| niemeyer | jdstrand: It's trivial for a process to provide N dbus services | 17:40 |
| jdstrand | BusName= is a well-known name that clients connect to | 17:40 |
| jdstrand | then they can add any number of interfaces, etc | 17:40 |
| niemeyer | jdstrand: Okay, I'll buy that and pretend it's all fine while breathing in a bag | 17:40 |
| zyga | as long as systemd has the constrain that one bus name per process is the way to go, we can expect this not to be a problem for the immdeiate future where with existing snaps | 17:41 |
| zyga | constraint* | 17:41 |
| jdstrand | reading the systemd service specification, systemd doesn't seem to support multiple BusNames in a single service file | 17:41 |
| zyga | I think this is fine, I wonder how interface details will look like for something like bluez or nm | 17:42 |
| zyga | just <policy> ... blobs? | 17:42 |
| zyga | or something more elaborate | 17:42 |
| jdstrand | I think it is ok to say that is not supported | 17:42 |
| jdstrand | or at least, if you do it, your have to deal with systemd not making sure things are ordered correctly | 17:42 |
| niemeyer | zyga: We could in theory auto-assign the bus name to the application offering the bluez slot | 17:43 |
| niemeyer | zyga: But it's easier to leave those disentangled | 17:43 |
| niemeyer | At least for now | 17:44 |
| zyga | niemeyer: I agree, I think this will need more love later, especially with an evolving snap (e.g. new bluez) the interface implementation might also have to change | 17:44 |
| zyga | I feel there will be some lock-step necessary in general | 17:44 |
| zyga | but a simple approach is enough for 16.04 | 17:45 |
| jdstrand | I agree that we'll need to refine dbus once we start looking at things like bluez | 17:46 |
| jdstrand | I see in awe's bluez bus policy he has: | 17:46 |
| jdstrand | <allow own="org.bluez"/> | 17:46 |
| jdstrand | <allow own="org.bluez.obex"/> | 17:46 |
| jdstrand | but he ships two different daemons | 17:47 |
| jdstrand | bluez and obex | 17:47 |
| jdstrand | both are 'daemon: simple' | 17:47 |
| jdstrand | interesting | 17:48 |
| jdstrand | so he is opting out of systemd integration | 17:48 |
| zyga | jdstrand: maybe that's not deliberate | 17:48 |
| jdstrand | and saying "just start me however you want". it starts, dbus-daemon looks at the bus policy (which is combined in one file here) and dbus allows it to start | 17:49 |
| zyga | jdstrand: here we'd make two files (with the code I'm proposing) | 17:49 |
| zyga | hmmm | 17:49 |
| zyga | actually | 17:49 |
| zyga | that's bad | 17:50 |
| jdstrand | is it? | 17:50 |
| zyga | and interesting but bad | 17:50 |
| zyga | so bluez and obex are separate apps | 17:50 |
| zyga | they need separate slots | 17:50 |
| zyga | and separate interfaces | 17:50 |
| jdstrand | they are, but he used one bus config | 17:50 |
| jdstrand | but I think it would be ok to use 2 bus configs | 17:50 |
| zyga | to get two xml snippets that's appropriate to each app | 17:50 |
| zyga | then again dbus is not enforced per app really | 17:51 |
| zyga | it's enforced per bus name | 17:51 |
| zyga | right? | 17:51 |
| jdstrand | I don't know what you mean by enforce there | 17:51 |
| zyga | I feel that app/snippet/bus triplet is not so clean as in apparmor/seccomp | 17:51 |
| zyga | jdstrand: sorry perhaps my language is wrong | 17:51 |
| zyga | jdstrand: does dbus flitering care about our apps in _any_ way? | 17:51 |
| zyga | jdstrand: (dbus policy files) | 17:51 |
| jdstrand | traditionally, dbus policy files are plopped into a .d directory that dbus reads and decides what to do with it | 17:52 |
| jdstrand | I don't know if first wins or last wins or if it is undefined | 17:52 |
| jdstrand | so it is up to snappy to keep things clean | 17:52 |
| zyga | jdstrand: so we currently do a file-per-app | 17:53 |
| jdstrand | so the current approach I think is just fine | 17:53 |
| jdstrand | yeah, sure | 17:53 |
| zyga | jdstrand: (we could do something else but that's the status quo) | 17:53 |
| zyga | jdstrand: but my point is that it's a bit subtle | 17:53 |
| zyga | jdstrand: because from what I see we can have one app say "this and that bus policy applies" | 17:53 |
| jdstrand | well, sorta | 17:53 |
| zyga | jdstrand: and in reality that will affect *other* apps that just use that bus name | 17:53 |
| zyga | jdstrand: right? | 17:53 |
| jdstrand | with seccomp it is quite clear-- the file is what is the seccomp policy | 17:54 |
| jdstrand | with apparmor it is like dbus. the contents of the file could technically be for something else, multiple things, etc | 17:54 |
| jdstrand | we just need to add dbus files in a controlled way like we do with apparmor | 17:54 |
| zyga | jdstrand: the thing we won't catch though is people misassigning slots to apps | 17:55 |
| zyga | jdstrand: so looking at snap.yaml you will see that some interface is on some app | 17:55 |
| jdstrand | we control the interfaces, we control how the dbus files are written, so we should be ok | 17:56 |
| zyga | jdstrand: but in reality it will apply to a different app at runtime | 17:56 |
| zyga | jdstrand: and unless all such cases flag for manual review | 17:56 |
| zyga | jdstrand: we're going to miss it | 17:56 |
| jdstrand | if I assign nm to the bluez daemon, is the system supposed to prevent that? | 17:56 |
| zyga | jdstrand: well, that's a different problem, this is more like obex/bluez case above | 17:56 |
| jdstrand | lets leave manual review out of it for now. that is a whole other conversation | 17:57 |
| zyga | jdstrand: because it's not something that ubuntu-core-laucher applies / enforces on process startup | 17:57 |
| zyga | jdstrand: I think it's not a major problem | 17:57 |
| zyga | jdstrand: just a potential source of confusion | 17:57 |
| jdstrand | (cause it gets into safe/unsafe, etc which would be a distraction for landing stuff) | 17:57 |
| zyga | jdstrand: I'll take a break for home duties and I'll get back to udev and snap install support | 17:57 |
| zyga | jdstrand: we now have apparmor backend, seccomp reviewed and dbus with some changes (comments mailny I think) | 17:58 |
| jdstrand | zyga: the launcher doesn't, no. it is all dbus-daemon | 17:58 |
| jdstrand | I'm not done with dbus. I got distracted wby this conversation | 17:58 |
| zyga | jdstrand: so I think that's enough to get hello-world snap working :) | 17:58 |
| zyga | jdstrand: that's okay, it's not essential for initial stab at install support | 17:59 |
| zyga | jdstrand: I'll leave you to reviews and other work, ttyl | 17:59 |
| jdstrand | I think we should keep pushing the current dbus direction and refine as we look at bluez, pulse, nm, etc | 17:59 |
| jdstrand | zyga: bye, thanks! | 17:59 |
| niemeyer | jdstrand: Hmm | 17:59 |
| jdstrand | niemeyer: ? | 18:00 |
| niemeyer | jdstrand: we have the x(11) interface in already.. what does it do? | 18:00 |
| jdstrand | niemeyer: adds /etc/apparmor.d/abstractions/X | 18:00 |
| niemeyer | jdstrand: Which will ...? | 18:01 |
| jdstrand | niemeyer: essentially a few files in home for X to work, a few things in /usr and connection to the X socket | 18:01 |
| niemeyer | jdstrand: Okay, that's not quite what we had in mind in that meeting, same reason as the bluez discussion above | 18:01 |
| Netphreak | Hi, guys! | 18:02 |
| jdstrand | I implemented it in the context of sdoc, not for providing an X server as a snap | 18:02 |
| Netphreak | Any news om snappy om rpi3? | 18:02 |
| niemeyer | jdstrand: Hmm.. so by "a few files in home for X to work" you actually mean "for X applications to connect to X" rather than "for the X server itself to work" | 18:03 |
| niemeyer | ? | 18:03 |
| jdstrand | niemeyer: yes, exactly | 18:03 |
| jdstrand | niemeyer: this is the client part | 18:03 |
| niemeyer | jdstrand: Aha, gotcha, thanks | 18:03 |
| jdstrand | I want to run xeyes on classic | 18:03 |
| niemeyer | jdstrand: Yep, got it.. that's fine then | 18:04 |
| niemeyer | Stepping out for some sprint-related errands.. back later | 18:06 |
| code1o6 | I'm having issues publishing my app to the ubuntu store. I currently have version 1.1.0 in ubuntu 15.04. Should I add sudo add-apt-repository ppa:snappy-dev/snapcraft-daily ? I need my app to be for 15.04 snappy core systems | 19:10 |
| code1o6 | snapcraft login apparently doesn't exist in 1.1.0 | 19:11 |
| kyrofa | code1o6, you'll need to upload your snap via myapps | 19:20 |
| kyrofa | code1o6, http://myapps.developer.ubuntu.com/ | 19:20 |
| kyrofa | Login to your account and upload your snap there | 19:20 |
| kyrofa | code1o6, snapcraft 2.x will do that for you, 1.x does not | 19:20 |
| === blr_ is now known as blr | ||
| code1o6 | kyrofa, thank you | 19:39 |
| code1o6 | kyrofa, I already have an account where do you click next | 19:41 |
| kyrofa | code1o6, click the Ubuntu Core tab at the top, and then the "New Package" button | 19:42 |
| josepht | kyrofa: what's needed to run the snapcraft example_tests? './runtests.sh examples' on 16.04 is trying to create 15.04 images with ubuntu-device-flash and snappy is failing with "Unknown command `internal-unpack'." | 19:45 |
| kyrofa | josepht, try ./runtests.sh examples --skip-install | 19:45 |
| kyrofa | josepht, by default it wants to install them into an ubuntu core machine and actually run them | 19:46 |
| kyrofa | josepht, if you have one lying around you can use that too, of course | 19:46 |
| kyrofa | josepht, check out examples_tests/__main__.py for the options | 19:47 |
| josepht | kyrofa: ack, thank you | 19:47 |
| sergiusens | kyrofa, josepht much better `python3 -m examples --help` | 19:58 |
| kyrofa | sergiusens, josepht or that. If you like pretty help printouts instead of source code | 19:59 |
| sergiusens | kyrofa, lol; I want to get rid of the runtests script; it has less options than running the package | 20:00 |
| kyrofa | sergiusens, I'm on board with that | 20:00 |
| sergiusens | josepht, if your snap is failing to build, run it in a cleanbuild; so `snapcraft cleanbuild` | 20:03 |
| kyrofa | josepht, yeah good idea-- cleanbuild the git example and you'll probably find the missing dependencies | 20:03 |
| code1o6 | kyrofa, thanks for the help! | 20:16 |
| code1o6 | I got rejected for this error | 20:16 |
| code1o6 | required description field not specified snappy-systemd_package_yaml_description_present (webui) | 20:16 |
| kyrofa | code1o6, your service needs a description | 20:16 |
| code1o6 | description: A basic webserver | 20:17 |
| code1o6 | https://github.com/arfvidsonUIS/unisys-test-snappy/blob/master/snapcraft.yaml | 20:17 |
| code1o6 | here is my snapcraft.yaml ^^ | 20:17 |
| code1o6 | kyrofa, could you take a look | 20:18 |
| kyrofa | code1o6, the webui service needs a description of its own | 20:19 |
| code1o6 | so just add description in line 13 | 20:19 |
| kyrofa | code1o6, right | 20:20 |
| zyga | jdstrand: hey | 20:26 |
| zyga | jdstrand: still around? | 20:26 |
| code1o6 | How long is the review process? | 20:28 |
| code1o6 | I'm using network-admin | 20:28 |
| zyga | jdstrand: https://github.com/ubuntu-core/snappy/pull/768/files | 20:29 |
| zyga | jdstrand: last one :) | 20:29 |
| kyrofa | code1o6, yeah network-admin requires a manual review. It could take some time | 20:30 |
| code1o6 | hours, days, or months? | 20:33 |
| code1o6 | kyrofa, ^^ | 20:34 |
| zyga | jdstrand: https://github.com/ubuntu-core/snappy/pull/769/files | 20:34 |
| kyrofa | code1o6, no clue. I'm not one of the reviewers, sorry | 20:34 |
| code1o6 | kyrofa, thanks for the information | 20:34 |
| jdstrand | tyhicks: fyi, https://code.launchpad.net/~jdstrand/ubuntu-core-launcher/preprocessor/+merge/290652 | 20:39 |
| jdstrand | zyga: looking | 20:40 |
| zyga | jdstrand: nice | 20:40 |
| zyga | jdstrand: I'm working on one more patch for apparmor, to remove the binary cache | 20:40 |
| tyhicks | jdstrand: I'm in the process of reviewing that MP | 21:06 |
| jdstrand | cool, thanks | 21:07 |
| josepht | sergiusens, kyrofa: thanks for the tips. Sorry I got distracted by a baby squirrel that needed some help. | 21:28 |
| zyga | jdstrand: https://github.com/ubuntu-core/snappy/pull/770 | 21:54 |
| zyga | jdstrand: I'm about to EOD (day is running out) | 21:55 |
| zyga | jdstrand: I'll see you tomorrow | 21:55 |
| jdstrand | zyga: have a nice evening :) | 21:55 |
| zyga | jdstrand: likewise :) | 21:56 |
| chiluk | Hey what arm64 boards are people getting for running snappy/ubuntu on? right now it looks like pi3 and odroid-c2, and odroid-xu4 | 23:08 |
| chiluk | are all pretty awesome. | 23:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!