[08:35] <dholbach> good morning
[10:20] <ogra_> mvo, Chipaca, do you guys know if we expose the package version somewhere in the environment of snap services/binaries (i.e. how would my app know it has just been upgraded)
[10:21] <ogra_> i think we need some mechanism to make the package know when it needs to run any confi migration scripts
[10:22] <ogra_> *config
[10:22] <mvo> ogra_: it should be available via SNAP_VERSION
[10:22] <ogra_> ah, thanks !
[10:22] <mvo> ogra_: hm, there was discussion about providing a native hook for this from snappy itself
[10:23] <JamesTait> Good morning all; happy Monday, and happy Computer Security Day! 😃
[10:23] <ogra_> yeah, that would be cool ... but for the moment i can use that var ... (just updating a stamp file and compare on service start)
[10:27] <ogra_> geez, "snappy build" is amazingly slow o armhf :/
[10:27] <ogra_> *on
[10:27] <ogra_> 11min for a package that takes 2min to build on amd64
[10:30] <longsleep> Is /writable/cache somehow used on boot again? I see some service duplication and the only location where the old service file exits is in /writable/cache/system
[10:32] <ogra_> it should be readonly mounted after boot ... but nothing else
[10:32] <ogra_> /writable/cache/system that is
[10:33] <longsleep> ogra_: yes it is mounted ro there, but something seems to copy all the files in there on boot
[10:33] <longsleep> ogra_: could that be?
[10:33] <ogra_> i dont think so
[10:33] <ogra_> it is your "other" readonly partition
[10:34] <longsleep> right - this is very strange
[10:34] <longsleep> i delete a file from /etc/systemd/service and disable the service with systemctl as well, reboot then it is there again
[10:34] <ogra_> probably some generator ?
[10:35] <ogra_> though even that should respect that you disabled it
[10:35] <longsleep> the service comes from a snap - snap is still installed as newer version
[10:35] <longsleep> the version the service gets generated for is not on the disk - at least i cannot find it
[10:36] <longsleep> i see the issue for more than one snap though. It seems like when a builtin snap is updated, the systemd service of the version which is oem is recreated on boot for unknown reason
[10:37] <ogra_> that sounds definitely like a bug
[10:37] <longsleep> ogra_: yeah, though i was unable to figure out how that even happens yet
[10:41] <longsleep> so, before reboot the service was only in /writable/cache/system/etc/systemd/system, after reboot it is in /etc/systemd/system - so something must copy it
[10:43] <ogra_> longsleep, i guess the issue is that it is in /writable/cache/system/etc/systemd/system at all ...
[10:43] <ogra_> thats a readonly system ... no snap should be able to put anything there ever
[10:43] <longsleep> ogra_: true, but those are put there by u-d-f i think
[10:44] <longsleep> ogra_: the snaps are preinstalled with the oem snap
[10:44] <ogra_> hmm, sounds wrong to me to put them in the readonly partition
[10:45] <longsleep> yeah, they will never go away
[10:45] <longsleep> i would be fine with that, but how are they cloned on boot?
[10:45] <longsleep> i mean that causes the problem after all
[10:49] <longsleep> ogra_: i think it is synced in the initrd
[10:51] <ogra_> longsleep, i wouldnt see how
[10:51] <longsleep> ogra_: well, there is some code in the ubuntu-core-rootfs of the initrd which does some copying
[10:51] <ogra_> yes
[10:51] <longsleep> ogra_: maybe i use ancient version again
[10:51] <ogra_> one sec
[10:52] <ogra_> bah, i was hoping for a wrong setting in /etc/system-image/writable-paths ... but seems the cache path is actually hardcoded
[10:53] <ogra_> hmm, k ...
[10:53] <ogra_> the initrd doesnt mount it at all
[10:54] <ogra_>         if [ -n "$other" ]; then
[10:54] <ogra_>                 echo "$other /writable/cache/system auto defaults,ro 0 0" >> "$fstab"
[10:54] <ogra_>         fi
[10:54] <longsleep> right
[10:54] <ogra_> thats all it does ... right before run-init
[10:54] <ogra_> so if there is any syncing thats not happening in the initrd
[10:54] <longsleep> maybe it runs into one of the other conditions which do cp -A
[10:55] <longsleep> i mean the file ending up in /etc/systemd/system has the same timestamp as the one in /writable/cache/system/etc/systemd/system
[10:56] <ogra_> well, there must be some systemd unit that copies it
[10:56] <ogra_> when processing fstab
[10:56] <longsleep> ok let me check if i can find something there
[11:33] <longsleep> ogra_: well, i could not find it and now i even removed the file from /writable/cache/system/ and it still gets recreated magically in /etc/systemd/system
[11:33]  * longsleep has no idea where it comes from
[11:39] <fgimenez> hi Chipaca, have a minute?
[11:55] <dholbach> mvo, can you (or somebody else) help with https://code.launchpad.net/~jdstrand/click-reviewers-tools/click-reviewers-tools.snappy1604/+merge/278218?
[12:46] <ogra_> Nov 30 13:44:32 aleph2 systemd[1]: Starting minidlna DLNA server...
[12:46] <ogra_> Nov 30 13:44:32 aleph2 ubuntu-core-launcher[26252]: /apps/upnp-server-amd64.sideload/IGccOWeCMeET/minidlnad: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /apps/upnp-server-amd64.sideload/IGccOWeCMeET/usr/lib/x86_64-linux-gnu/libsnappy.so.1)
[12:46] <ogra_> Nov 30 13:44:32 aleph2 systemd[1]: Reloading.
[12:46] <ogra_> woah
[12:46] <Chipaca> jdstrand_: tyhicks: ping about snapd and ACLs
[12:48] <Chipaca> well, not ACLs, but permissions on the unix socket and SO_PEERCRED
[12:59] <mvo> dholbach: I have a look after the meeting, thanks
[13:00] <longsleep> Chipaca: Hey, maybe you can help me in finding the script which creates snappy systemd services in /etc/systemd/system/ on boot. I have the problem that a service keeps appearing there while that snap version is not installed
[13:01] <mvo> longsleep: do you install something that has a service duing your u-d-f run?
[13:01] <longsleep> mvo: yes
[13:02] <longsleep> mvo: the oem snap has several snaps as built-in
[13:02] <mvo> longsleep: I think there is a bug in u-d-f
[13:02] <longsleep> mvo: when updating those, the old systemd service gets not removed and recreated on boot
[13:02] <longsleep> mvo: yeah that makes sense, though where does u-d-f store the information so the service can actually be recreated
[13:07] <dholbach> mvo, cool, thanks
[13:21] <ogra_> jdstrand_, is the chwon blocking really necessary given we cant actually chown anything outside of the writable area of the snap anyway ? i have massive probs with it atm trying to package something that uses two services which both call fchown/fchown32
[14:39] <tyhicks> Chipaca: hey - I need some more context as I don't know if I've heard anything about that yet
[14:40] <Chipaca> tyhicks: you probably haven't :)
[14:40] <Chipaca> tyhicks: you remember snapd, the snappy daemon that runs as root, that you connect to over a unix socket?
[14:40] <tyhicks> Chipaca: yep
[14:40] <Chipaca> tyhicks: that socket is 0600 root:root right now
[14:41] <Chipaca> tyhicks: wanting to relax that so regular users can connect
[14:41] <Chipaca> tyhicks: so, server uses SO_PEERCREDS on the socket to determine uid, deny access to privileged ops to non-privileged users
[14:41] <tyhicks> ok
[14:42] <Chipaca> tyhicks: would like you or jamie to go over what/how we're doing that before actually lowering the 0600
[14:42] <tyhicks> Chipaca: is there a MP?
[14:43] <Chipaca> tyhicks: the code that does SO_PEERCRED is already in master
[14:43] <Chipaca> tyhicks: 1 sec and i'll point you at the relevant file itself
[14:44] <Chipaca> tyhicks: https://github.com/ubuntu-core/snappy/blob/master/daemon/ucrednet.go
[14:44] <tyhicks> Chipaca: ack, I should be able to have a look in a day or two
[14:44] <Chipaca> tyhicks: that's the wrapper that knows about SO_PEERCRED and uses it to get the uid for unix connections
[14:44] <tyhicks> (maybe today)
[14:45] <Chipaca> tyhicks: and then https://github.com/ubuntu-core/snappy/blob/master/daemon/daemon.go#L67 checks things before allowing access
[14:46] <tyhicks> ok
[14:46] <Chipaca> tyhicks: it's a rather hackish first pass that stuffs the uid in the RemoteAddr of the transfer, but modulo that it seems sane to me
[14:47] <Chipaca> transport*
[14:47] <Chipaca> tyhicks: yeh, no hurry
[14:47] <Chipaca> well, no hurry beyond the usual :-)
[15:38] <rickspencer3> mvo, can you please give me a link to the correct rolling image for rpi2 if I want to install and test 16.04 rolling?
[15:38]  * rickspencer3 notes the web site still points (correctly, I think) to 15.04
[15:39] <mvo> rickspencer3: we don't have a pre-build xenial image right now (unless ogra_ did some for rpi2). you can use ubuntu-device-flash to build an image. maybe it would be a good idea to make a snapshot available for easier testing
[15:40] <rickspencer3> ack
[15:57] <longsleep> so, what other tool on a snappy system can create systemd services for snaps? I still have not found the reason why old services keep appearing on boot. They are not generated by /usr/bin/snappy :/
[16:00] <Chipaca> longsleep: what are the files that won't die?
[16:00] <ogra_> mvo, no, i didnt, i would like us to eventually produce whole images for xenial in an automated way though
[16:01] <ogra_> s/for xenial//
[16:01] <longsleep> Chipaca: i have snaps with services installed via oem built-in - when those get updated everything seems fine. But on reboot the service files reappear in /etc/systemd/system/
[16:02] <longsleep> Chipaca: i have looked and looked but seem unable to find out how these files are generated / where they come from :/
[16:03] <Chipaca> longsleep: you mean you have a snap that you include from oem, that in an update removes a service? or is it services for old versions that appear?
[16:04] <longsleep> Chipaca: spreedbox-led_ledd_0.0.9-4.service is the new service, spreedbox-led_gnatsd_0.0.6-1.service the old. spreedbox-led_gnatsd_0.0.6-1.service is removed after update. Then reboot and spreedbox-led_gnatsd_0.0.6-1.service is there again
[16:05] <longsleep> Chipaca: it is the same problem for all services installed via oem
[16:05] <longsleep> Chipaca: on update, the old service gets removed fine. Then reboot and it is back (and fails to start)
[16:05] <longsleep> Chipaca: what troubles me is that i seem to be unable to figure out where it comes from
[16:06] <Chipaca> longsleep: could i see the output of 'sudo journalctl' on a reboot with these things happening?
[16:06] <Chipaca> longsleep: firstboot is the thing that might be doing that, but it shouldn't be running
[16:07] <longsleep> Chipaca: sure
[16:07] <Chipaca> and ... yeah, it doesn't make sense
[16:09] <longsleep> Chipaca: it says started firstboot setup every time
[16:10] <longsleep> let me check when i remove the firstboot stamp and run it manually
[16:11] <longsleep> Chipaca: no, removing the stamp and running snappy firstboot did not create the service file again
[16:11] <Chipaca> phew
[16:12] <longsleep> Chipaca: i have a patched version of snappy, which adds a custom X- header to the service file when snappy generates it, for the file which keeps reappearing it does not have that header
[16:12]  * Chipaca looks up phone numbers of exorcists
[16:12] <longsleep> Chipaca: it is either copied from some place or created from some other tool
[16:12] <Chipaca> longsleep: ooh, nice
[16:12] <Chipaca> ogra_: pingu
[16:12] <ogra_> yo yo
[16:13] <Chipaca> ogra_: is there anything in initrd/early boot that could be copying a service file?
[16:13] <ogra_> no
[16:13] <ogra_> hmm
[16:13] <ogra_> well
[16:13] <longsleep> It also needs to copy it from some place, i have removed all locations below /writable where that file could be found
[16:13]  * ogra_ checks something
[16:14] <Chipaca> longsleep: can you mount and see if it's in /etc *under* writable?
[16:14] <longsleep> Chipaca: mount what exactly?
[16:14] <Chipaca> longsleep: umm... system-a? partition #3 iirc
[16:15] <Chipaca> longsleep: on a brand new image
[16:15] <longsleep> Chipaca: sure - hold on
[16:15] <Chipaca> longsleep: (or on a booted one, really)
[16:15] <longsleep> Chipaca: brand new booted one - without upgrading?
[16:15] <Chipaca> longsleep: yep
[16:16] <longsleep> Chipaca: flashing now, takes 70 seconds
[16:16] <Chipaca> longsleep: ok. just mounting the image locally would also work :-)
[16:16] <longsleep> Chipaca: that would not be booted though
[16:17] <Chipaca> ah, sorry i meant booting it or not shouldn't make a difference to that partition
[16:17] <Chipaca> although, having said that, if it _did_ make a difference that'd be interesting in and of itself
[16:17] <ogra_> Chipaca, so the entry for /etc/systemd/system in /etc/system-image/writable-paths is "synced none none" so yes, content from the readonly fs will be synced on boot
[16:17] <longsleep> ah
[16:18] <ogra_> and etc gets processed from initrd
[16:18] <ogra_> (remember, we had to move it because of races)
[16:18] <longsleep> finally the mystery solved!
[16:18] <ogra_> well, the bug is that fragments from snaps are on the readonly partition
[16:19] <ogra_> that shouldnt be
[16:19] <longsleep> /media/longsleep/system-a/etc/systemd/system/spreedbox-led_gnatsd_0.0.6-1.service
[16:19] <longsleep> that is the non booted image
[16:19] <ogra_> right
[16:19] <Chipaca> so the bug is that those are getting created by snappy during the u-d-f unpack/install thing
[16:19] <ogra_> yeah
[16:20] <ogra_> they would have to go into the writable space
[16:20] <longsleep> i see - so this needs fixing in u-d-f
[16:20] <ogra_> since they are from snaps :)
[16:20] <Chipaca> longsleep: in snappy, actually
[16:20] <ogra_> (all of the snaps shuld go into the writable space in fact)
[16:20] <longsleep> Chipaca: right
[16:20] <Chipaca> (u-d-f calls into snappy)
[16:20] <longsleep> Chipaca: so add a flag or something, similar to the existing ones
[16:20] <Chipaca> yep
[16:21] <Chipaca> flag already exists
[16:21] <Chipaca> InhibitHooks
[16:21] <ogra_> Chipaca, but if udf doesnt set up the mounting in a way that the snap bits land in writable places you have lost
[16:21] <ogra_> not necessarily a snappy bug imho
[16:21] <Chipaca> ogra_: the service files should not be created at udf time; firstboot creates them
[16:21] <longsleep> that would be easy to fix
[16:22] <longsleep> so for testing, i could remove the snap services from system-a and then do a boot
[16:22] <longsleep> right?
[16:22] <Chipaca> longsleep: yep
[16:23]  * longsleep gives it a try
[16:23] <ogra_> Chipaca, aha ... nontheless, snap fragments should not live in the readonly rootfs
[16:24] <ogra_> and i assume there is no "boot" happening when udf assembles the img ... whihc means if you do anything chrooted in the img you wont have the mountpoints set up
[16:25] <ogra_> (i can be wrong indeed ... just guessing)
[16:25] <longsleep> well, i removed the service files before firstboot, but firstboot did not create them
[16:27] <longsleep> Chipaca: yeah not installing the services in u-d-f is bad as they are not created again and update fails as the service is not loaded
[16:27] <Chipaca> :'-(
[16:27]  * Chipaca forgot how to emoticon
[16:28] <longsleep> Where do you want to have the bug for this? github snappy or udf on launchpad?
[16:28] <Chipaca> sergiusens: mvo: ping
[16:28] <Chipaca> longsleep: gimme a sec
[16:29] <Chipaca> so the easy way would be to hack udf to set things up properly
[16:29] <Chipaca> i think a better way would be to make snappy not activate anything from udf, and instead add that to firstboot (which i thought was one of the things oemconfig was doing anyway)
[16:29] <Chipaca> but there might be a reason not to do it this way
[16:29] <longsleep> Chipaca: yeah, i guess we can do that and somehow move the things to writable
[16:30] <Chipaca> hence me pinging mvo and sergiusens :-)
[16:30] <Chipaca> longsleep: writable is there at udf time, just needs bind-mounting properly (or things moved to the right place post hoc, which is tricky because of random cruft in /etc/systemd/system (that shouldn't be there anyway (but I digress)))
[16:31] <ogra_> +1 for firstboot, that is where it belongs
[16:31] <longsleep> Chipaca: so the other cruft in there should stay readonly ?
[16:32] <longsleep> ogra_: yes, though that is unlikely to happen for 15.04 right?
[16:32] <ogra_> yeah, for that the hack might be a better approach
[16:35] <sergiusens> Chipaca, the plan is to move it to firstboot
[16:35] <sergiusens> Chipaca, if you care to create the PR for it, great ;-)
[16:35] <ogra_> the PR ?
[16:36] <sergiusens> ogra_, pull request
[16:36] <ogra_> event planning ? cheerleaders, free food and flyers ? as in public relations ?
[16:36] <ogra_> aahh !
[16:36] <sergiusens> Chipaca, in any case, I'd prefer if the image creator just dropped the snaps (except kernel and os) into a defined location and firstboot do its thing
[16:37] <ogra_> +1
[16:37] <ogra_> isnt that what we do on the phone ?
[16:37] <ogra_> (for custom tarballs)
[16:38] <ogra_> jdstrand, i assume you missed my ping from this morning ?
[16:38] <sergiusens> ogra_, no; sadly no
[16:38] <sergiusens> unless it changed recently
[16:39] <ogra_> oh, i thought we did
[16:39] <ogra_> we really should :)
[16:40] <Chipaca> sergiusens: for 15.04 also?
[16:40] <mvo> Chipaca: sorry, I was in a meeting - so I think the issue that longsleep is seeing is fixed with something like http://bazaar.launchpad.net/~snappy-dev/goget-ubuntu-touch/all-snaps/revision/226
[16:40] <mvo> Chipaca: but I think that your idea of installing them on first boot is better, however this won't work for the OS snap (as it needs to be ready for first-boot)
[16:41] <Chipaca> no no
[16:41] <mvo> no?
[16:41] <Chipaca> my idea was *activating* them on first boot
[16:41] <Chipaca> not installing them
[16:41] <Chipaca> in squashfs world that might be the same thing tho :-)
[16:42] <Chipaca> but in 15.04 having the unpack done at build time, and the activation at first boot, seems sane and should be easily doable
[16:42] <Chipaca> but i don't know if we want to, and if there is going to be a release of this
[16:42] <Chipaca> hence, calling you
[16:43] <ogra_> well, we didnt stop doing monthlies for 15.04, did we ?
[16:43] <ogra_> to have the images pick up -security and -updates
[16:45]  * Chipaca waits for mvo to confirm that
[16:46] <longsleep> Chipaca: to hack it, where exactly do the files need to go on the writable partition? i see a system-data folder there
[16:47] <longsleep> Chipaca: create etc/systemd/system in there ?
[16:47] <mvo> Chipaca: ups, sorry. indeed, this does make sense. I'm not sure if/when we do a 15.04 release though either, maybe worth bringing up at the next standup?
[16:48] <mvo> longsleep, Chipaca: I need to run very soon to play hockey, however I'm happy to discuss this further tonight/tomorrow
[16:48] <ogra_> mvo, we'll need to sit down tomorrow too to talk about allsnaps and the build system
[16:48] <Chipaca> i'll look at getting a branch up with this
[16:48] <Chipaca> also, we need to get edge working on arm again
[16:48] <mvo> ogra_: sure
[16:49] <Chipaca> and plan the next monthly 1504 (which i think we've slipped, unless time has done its usually stretchy snappy thing)
[16:49] <mvo> Chipaca: yeah, no idea about the test failure right now :/ still need to investigate on a porter machine
[16:49] <longsleep> mvo: sure, i think i understood the problem and might figure out a hack for now - but it would be awesome if there would be a fix for 15.04
[16:49] <Chipaca> mvo: blame ogra_, then he'll fix it :-p
[16:50] <longsleep> mvo: also this one would be nice on https://github.com/ubuntu-core/snappy/issues/189 - we have patched it locally but i guess others might have the issue as well
[16:50] <ogra_> Chipaca, heh, ask davmor2 ... that only works sometimes
[16:50] <Chipaca> longsleep: i can't be sure offhand. easiest way would be to see on upgraded machine what /writable looks like
[16:50] <longsleep> Chipaca: good idea thanks
[16:50] <mvo> longsleep: aa, nice
[16:50] <davmor2> ogra_: no it works all the time, you just go blame the right person :D
[16:53] <longsleep> sync
[16:53] <longsleep> ups :)
[16:55] <rickspencer3> ogra_, are there steps I can follow to make a rolling 16.04 rpi2 image today?
[16:58] <Chipaca> rickspencer3: u-d-f doesn't work?
[16:58] <rickspencer3> Chipaca, I did not say that, I was looking for documentation
[16:59] <rickspencer3> :)
[16:59] <ogra_> rickspencer3, once sec i can give you a cmdline (the rpi püage needs updating for that)
[17:02] <longsleep> Chipaca: ok i got scripting which fixes the problem: http://paste.ubuntu.com/13579233/
[17:02] <longsleep> Chipaca: i think i can add that as a post process step to our image builder
[18:19] <ogra_> rickspencer3, sudo ubuntu-device-flash core rolling --channel edge --oem pi2.canonical --enable-ssh --device raspi2_armhf --output raspi2-rolling.img
[18:19] <ogra_> (sorry, i had not forotten you :) )
[18:19] <ogra_> (and ignore the moaning about azure :) )
[18:55] <jdstrand> Chipaca: hey, fyi, going through old irc (I was on holiday last week). I updated /usr/share/apparmor/easyprof/policygroups/ubuntu-core/15.04/snapd to have /run/snapd.socket in 15.04.12~ppa12 on Nov 13. I looks like stable hasn't been updated since then
[18:57] <Chipaca> jdstrand: a'yup
[18:57] <Chipaca> jdstrand: welcome back to the world of the living, and all that
[18:59]  * rickspencer3 tries
[19:03] <Chipaca> ogra_: unless you've uploaded a pi2 since the channels work, that needs to be pi2.canonical/stable
[19:03] <ogra_> Chipaca, really ? udf cares ?
[19:03] <Chipaca> no, it doesn't care, which is why that works :-)
[19:04] <ogra_> ah :)
[19:04] <Chipaca> it's just passing that on to the CPI REST API
[19:04] <ogra_> rickspencer3, ^^
[19:04] <Chipaca> and CPI cares. In fact that's all it cares about ;-)
[19:04] <Chipaca> sudo ubuntu-device-flash core rolling --channel edge --oem pi2.canonical/stable --enable-ssh --device raspi2_armhf --output raspi2-rolling.img
[19:04] <Chipaca> ^ seems to work
[19:04] <rickspencer3> oh
[19:05] <Chipaca> that /stable is a temporary workaround until we get things into the edge channel itself
[19:05]  * rickspencer3 tries again ;)
[19:06]  * rickspencer3 happily kicks off his "azure" image
[19:08] <rickspencer3> ogra_, Chipaca seemed like it downloaded the parts and built the image quite quickly
[19:08]  * rickspencer3 prepares to dd
[19:08] <ogra_> good
[19:08] <rickspencer3> ogra_, just dd it to sbx as per usual, right?
[19:08] <ogra_> yeah
[19:08] <ogra_> all the same for all images :)
[19:10]  * rickspencer3 dds and waits
[19:28] <Chipaca> http://people.canonical.com/~john/wow-so-peercred-much-access-levels.gif btw
[19:29] <Chipaca> tyhicks: ^ might be relevant (or not)
[19:34] <tyhicks> Chipaca: that's showing that the access checks aren't working as expected?
[19:34] <Chipaca> tyhicks: no, it's showing that they are
[19:35] <tyhicks> ah, right
[19:35] <Chipaca> tyhicks: in retrospect i should have paused before hitting enter on 'sudo !!'
[19:35] <Chipaca> assuming that is what tripped you up :)
[19:36] <tyhicks> opening up the socket to be world read/write today means that root is still required
[19:36] <tyhicks> yes, I think that is what tripped me up
[19:37] <Chipaca> tyhicks: root is still required <- for privileged operations you mean?
[19:39] <sandGorgon> hey guys... is there a snappy based ISO that I can try out and play with ? I'm looking at http://cdimage.ubuntu.com/daily-live/current/xenial-desktop-amd64.iso but dont know if it is intended with dpkg or snappy
[19:40] <Chipaca> sandGorgon: not an ISO. What are you wanting to play _on_?
[19:40] <tyhicks> Chipaca: yes - your gif is showing that root is required for privileged operations even though anyone can write to the socket - correct?
[19:40] <Chipaca> tyhicks: correct
[19:40] <tyhicks> got it
[19:41] <sergiusens> elopio, do you feel good about releaseing current master as 0.6?
[19:41] <Chipaca> tyhicks: didn't create the gif just for you, but thought it might be useful for you as well
[19:42] <Chipaca> sandGorgon: the snaps you can download from https://developer.ubuntu.com/en/snappy/start/ work in kvm, or you can dd them onto a sd card or usb stick and boot off of that
[19:42] <sandGorgon> Chipaca, this may sound stupid... but there were all these articles that mentioned that the next version of ubuntu will have a snappy-based flavor . so I was wondering if there were any builds of a desktop version with snappy.
[19:43] <Chipaca> sandGorgon: no, it does not sound stupid
[19:43] <tyhicks> Chipaca: it will be helpful - thanks!
[19:44] <Chipaca> sandGorgon: but things might have been lost in translation / repetition, as as far as I know there isn't a plan to have a snappy desktop version, but to be able to use snappy on the desktop, which is not quite the same
[19:45] <Chipaca> sandGorgon: i don't know how far along those plans are, though
[19:48] <sandGorgon> Chipaca, "Ubuntu 16.04 LTS will be able to run Snappy packages
[19:48] <sandGorgon> Will Cooke, the Ubuntu Desktop lead, announced during a Unity 7 discussion at the Ubuntu Online Summit that they are working to bring Snappy packages to the regular Ubuntu flavor, with Unity 7."
[19:48] <sandGorgon> I was wondering if I could start playing with it on the desktop... but maybe I'm jumping in too early. my bad... I can wait ;)
[19:49] <lotuspsychje> sandGorgon: install xenial development branch and apt-cache search snappy
[19:49] <lotuspsychje> and start fool around
[19:49] <Chipaca> sandGorgon: yes, snappy packages, but not a snappy system
[19:49] <sandGorgon> lotuspsychje, will do ;)
[19:55] <lotuspsychje> sandGorgon: ive also tested unity8 on xenial
[19:55] <lotuspsychje> sandGorgon: also early stage now, so it looks pretty much like the phone version
[19:55] <sandGorgon> lotuspsychje, oh.. is it usable ?
[19:56] <lotuspsychje> sandGorgon: yes, mouse support, browsing
[19:56] <sandGorgon> lotuspsychje, ah ok.. i'll survive probably (P.S. im more of a gnome guy)
[19:58] <lotuspsychje> sandGorgon: then test the ubuntu-gnome xenial development branch
[19:58] <sandGorgon> lotuspsychje, that's what's downloading right now
[20:09] <sergiusens> elopio, https://github.com/ubuntu-core/snapcraft/pull/127
[22:03] <jdstrand> sergiusens: catching up on irc backscroll from holiday
[22:03] <jdstrand> < sergiusens> Chipaca, 2015/11/24 08:43:59.067839 security.go:205: [sc-filtergen --include-policy-dir=/var/lib/snappy/seccomp --policy-vendor=ubuntu-core --policy-version=15.04 --template=network-status --policy-groups=networking] failed
[22:04] <jdstrand> sergiusens: you probably figured this out, but --template=network-status is wrong. the template is 'default' (ie, unspecified) and you should use caps: [ network-client, network-status ]
[22:07] <sergiusens> jdstrand, I haven't looked too much into it, it is just related to https://bugs.launchpad.net/snapcraft/+bug/1519251
[22:13] <jdstrand> sergiusens: based on the sc-filtergen denial, the package yaml is using 'security-template: network-status'. It shouldn't do that
[22:14] <jdstrand> s/denial/error/
[22:16] <jdstrand> Chipaca: fyi, I see in backscroll you pinged me about snapd and ACLs and that tyhicks responded. I will leave that topic to the two of you them
[22:19] <tyhicks> jdstrand: yes, I'm going to review the code
[22:19] <tyhicks> (card already created)
[22:20] <jdstrand> ogra_: re chown for services-- you mentioned massive problems. what are the problems? what are they chowning to? there is nothing they can legitimately chown to other than root, which is the user
[22:21] <jdstrand> ogra_: but to more simply answer your question-- it is a valid point that you need write access to the file to chown it. therefore, it makes some sense to allow these syscalls since apparmor blocks the file access
[22:22] <jdstrand> ogra_: however, we did not allow all of chown yet because we didn't understand the scope of issues at first and because, again, nothing valid to chown to
[22:24] <jdstrand> ogra_: couple that with seccomp arg filtering that we will hopefully have for 16.04. with that we'll say you can chown to 'root' for example (probably fixing your issue but in a different way), but disallow chown to 'nobody' or 'www-data'. if we decide to allow per-app user ids, we'd allow chown to that too
[22:25] <jdstrand> ogra_: but I didn't want to open the floodgates on that just yet, cause apps might hardcode things and do odd stuff, changing ownership to invalid things which might cause unexpected interactions
[22:26] <jdstrand> so proceeding with caution there. but as mentioned, the seccomp arg filtering alone will likely fix the obstacle you are facing
[22:26] <jdstrand> (with the accompanying policy updates)
[22:26] <jdstrand> tyhicks: thanks
[22:28] <ogra_> jdstrand, well, lighttpd and sqlite both only use fchown when they are run as root to chown files to the right UIDs ...
[22:28] <ogra_> and as it happens i'm just assembling something that uses both :)
[22:30] <jdstrand> ogra_: yeah, I talked about sqlite in snappy-app-devel-- I think we should probably patch it. lighthttpd is doing the exact same thing or chowning to some other user?
[22:30] <ogra_> ("to the right UIDs" typically to the UIDs defined in the config file)
[22:30] <jdstrand> what are you putting in that config file?
[22:31] <jdstrand> we don't have per-app user ids yet (see mailing list)
[22:31] <ogra_> well, i'm not really clear what lighttpd does, i cant find any trace of "chown" in the source
[22:32] <ogra_> i indeed dont put a user into that config file ... interesting fact is that lighttpd doesnt complain about fchown on amd64
[22:32] <jdstrand> ogra_: is this a xenial system?
[22:32] <ogra_> amd64 is 15.04 edge ... armhf is xenial edge
[22:33] <jdstrand> ogra_: on the xenial system, you can do the security-override method to unblock you while you investigate. eg:
[22:33] <jdstrand> services:
[22:33] <jdstrand>   - name: foo
[22:33] <jdstrand>     security-override:
[22:33] <ogra_> i use lighttpd's webdav module ... i guess that links in some sqlite stuff or so
[22:33] <jdstrand>       syscalls: [ fchown32, chown, ... ]
[22:33] <jdstrand> perhaps
[22:33] <jdstrand> and sqlite is doing the chown to root unconditionally to root
[22:33] <ogra_> yeah, i had that working at some point (and then threw everything away and started to patch the apps :P )
[22:34] <ogra_> right
[22:34] <ogra_> so it is just a pointless syscall
[22:34] <ogra_> but it is as pointless that we block it imho
[22:35] <jdstrand> well, I don't know about that
[22:35] <ogra_> given you cant chown anything outside of your confinement
[22:35] <jdstrand> I mentioned interactions
[22:37] <ogra_> jdstrand, btw, one thing that struck me ... how do we protect maintainers/developers from spp vulnerabilities ... i mean ... my https runs as root ... since i need to mangle the config it lives in $SNAP_APP_DATA_PATH ... where also my webroot needs to live ... if there is an issue with the webserver someone can just later my config remotely
[22:37] <ogra_> s/spp/app/
[22:37] <ogra_> s/later/alter/
[22:38] <ogra_> i was wondering if there is any way to protect us from such things
[22:39] <jdstrand> ogra_: snappy doesn't help with that. if there is a vulnerability in the app itself and it can scribble out to files, it could overwrite its configuaration, db files, etc. I mentioned this in my email on user ids-- this is one reason to support them
[22:40] <ogra_> oh, so you want to do some extrausers magic on a per-snap base ?
[22:40] <jdstrand> the easiest thing we can do which everyone already understands is allow for opt-in app ids
[22:40] <jdstrand> eg (and this is otoh, not designed or talked about beyond that thread and a couple of conversations):
[22:40] <jdstrand> services:
[22:40] <jdstrand> wait
[22:40] <jdstrand> name: foo
[22:40] <jdstrand> services:
[22:40] <jdstrand>   - name: bar
[22:41] <jdstrand>     app-user: true
[22:41] <jdstrand> then on install, that create the foo_bar user
[22:41] <jdstrand> creates
[22:41] <ogra_> hmm
[22:41] <jdstrand> that is a sort of 'system' user in that it is passwordless, etc
[22:41] <jdstrand> then the seccomp policy allows chowning to that user, etc
[22:42] <jdstrand> there are other ways to do that
[22:42] <jdstrand> but the basic idea is come up with something that namespaces the users to the package name
[22:42] <ogra_> i wonder if we couldnt teach libnss-extrausers to accept something like a passwd.d/ dir where snaps could drop their snippets
[22:42] <jdstrand> s/snaps/snappy install/ :)
[22:43] <ogra_> :)
[22:43] <jdstrand> app-user: true might be artificially limiting. perhaps a single service wants more than one app user. perhaps the users shouldn't be tied to the service at all, etc
[22:44] <jdstrand> anyway, those are the types of things to work out. I think there are some pretty good reasons for supporting them (see email thread) based on dev input
[22:44] <ogra_> right
[22:46] <jdstrand> maybe this is something we can discuss at the upcoming sprint if there is time
[22:47] <ogra_> the feb. one you mean ? yeah
[22:47] <jdstrand> no, the one I am going to next week :)
[22:47] <ogra_> ah
[22:47] <jdstrand> but sometime this cycle, sure
[23:06] <jdstrand> beuno, pindonga: hey, when is the next scheduled store rollout? I have a big merge to the review tools for all snaps that I'd rather get in sooner this week or wait until after next (and continue with manual reviews until then)
[23:06] <jdstrand> beuno, pindonga: basically, I don't want it hitting on the weekend or while I am sprinting in case I need to react quickly to something
[23:36] <ogra_> jdstrand, oh, btw ... if i put the above into my snapcraft.yaml i get
[23:36] <ogra_> Issues while validating snapcraft.yaml: 'apparmor' is a required property
[23:36] <ogra_> seems security-override wants an apparmor line too
[23:36] <jdstrand> ogra_: I think snapcraft needs to be updated for the new 16.04 yaml
[23:37] <jdstrand> sergiusens: I mentioned this elsewhere, but fyi ^
[23:37] <jdstrand> ogra_: oh, is that click review tools?
[23:37] <jdstrand> ogra_: yes, there is an MP about to land for that
[23:37] <ogra_> might be ... i get it on "snapcaft clean"
[23:37] <jdstrand> ogra_: can you paste the output?
[23:38] <ogra_> well, that was all output
[23:38] <ogra_> root@localhost:/upnp-server# snapcraft clean
[23:38] <ogra_> Issues while validating snapcraft.yaml: 'apparmor' is a required property
[23:38] <ogra_> root@localhost:/upnp-server#
[23:38] <jdstrand> sergiusens: fyi, not sure if snapcraft needs to be updated or not (just fyi)
[23:38] <jdstrand> that sounds like it does
[23:39] <ogra_> yeah
[23:40]  * ogra_ still doesnt get why lighttpd behaves different on armhf vs amd64 ... there is no fchown32 call on amd64 it seems 
[23:40] <jdstrand> yeah, there will be different syscalls between those
[23:41] <ogra_> well, different, sure ... but having the call on one arch and not on the other ?
[23:41] <jdstrand> fchown and fchown32 are maybe what you need
[23:41] <jdstrand> yeah, that is common
[23:42] <jdstrand> or at least, not uncommon
[23:42] <ogra_> really ?
[23:42] <ogra_> wow
[23:42] <jdstrand> I didn't know that either til having to look at all these
[23:49] <ogra_> oh man
[23:49]  * ogra_ slaps forehead 
[23:50] <ogra_> so i was seeing the syscall issue on armhf but not on amd64 ... because my snapcraft.yaml has a copy plugin that copies libsqlite to usr/lib/x86_64-linux-gnu ...
[23:50]  * ogra_ blushes