=== FourDollars_ is now known as FourDollars
=== marcoceppi_ is now known as marcoceppi
=== rsalveti_ is now known as rsalveti
=== Ursinha__ is now known as Ursinha_
=== plars-holiday is now known as plars
=== cprov_ is now known as cprov
=== mariogrip_ is now known as mariogrip
=== mariogrip_ is now known as mariogrip
=== rsalveti_ is now known as rsalveti
dholbachgood morning08:35
=== john-mca` is now known as john-mcaleely
=== davmor2_ is now known as davmor2
=== Guest74213 is now known as pixel_
=== mariogrip_ is now known as mariogrip
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:20
ogra_i think we need some mechanism to make the package know when it needs to run any confi migration scripts10:21
mvoogra_: it should be available via SNAP_VERSION10:22
ogra_ah, thanks !10:22
mvoogra_: hm, there was discussion about providing a native hook for this from snappy itself10:22
JamesTaitGood 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:23
ogra_geez, "snappy build" is amazingly slow o armhf :/10:27
ogra_11min for a package that takes 2min to build on amd6410:27
longsleepIs /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/system10:30
ogra_it should be readonly mounted after boot ... but nothing else10:32
ogra_/writable/cache/system that is10:32
longsleepogra_: yes it is mounted ro there, but something seems to copy all the files in there on boot10:33
longsleepogra_: could that be?10:33
ogra_i dont think so10:33
ogra_it is your "other" readonly partition10:33
longsleepright - this is very strange10:34
longsleepi delete a file from /etc/systemd/service and disable the service with systemctl as well, reboot then it is there again10:34
ogra_probably some generator ?10:34
ogra_though even that should respect that you disabled it10:35
longsleepthe service comes from a snap - snap is still installed as newer version10:35
longsleepthe version the service gets generated for is not on the disk - at least i cannot find it10:35
longsleepi 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 reason10:36
ogra_that sounds definitely like a bug10:37
longsleepogra_: yeah, though i was unable to figure out how that even happens yet10:37
longsleepso, 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 it10:41
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 ever10:43
longsleepogra_: true, but those are put there by u-d-f i think10:43
longsleepogra_: the snaps are preinstalled with the oem snap10:44
ogra_hmm, sounds wrong to me to put them in the readonly partition10:44
longsleepyeah, they will never go away10:45
longsleepi would be fine with that, but how are they cloned on boot?10:45
longsleepi mean that causes the problem after all10:45
longsleepogra_: i think it is synced in the initrd10:49
ogra_longsleep, i wouldnt see how10:51
longsleepogra_: well, there is some code in the ubuntu-core-rootfs of the initrd which does some copying10:51
longsleepogra_: maybe i use ancient version again10:51
ogra_one sec10:51
ogra_bah, i was hoping for a wrong setting in /etc/system-image/writable-paths ... but seems the cache path is actually hardcoded10:52
ogra_hmm, k ...10:53
ogra_the initrd doesnt mount it at all10:53
ogra_        if [ -n "$other" ]; then10:54
ogra_                echo "$other /writable/cache/system auto defaults,ro 0 0" >> "$fstab"10:54
ogra_        fi10:54
ogra_thats all it does ... right before run-init10:54
ogra_so if there is any syncing thats not happening in the initrd10:54
longsleepmaybe it runs into one of the other conditions which do cp -A10:54
longsleepi mean the file ending up in /etc/systemd/system has the same timestamp as the one in /writable/cache/system/etc/systemd/system10:55
ogra_well, there must be some systemd unit that copies it10:56
ogra_when processing fstab10:56
longsleepok let me check if i can find something there10:56
=== vrruiz_ is now known as rvr
=== chihchun is now known as chihchun_afk
longsleepogra_: 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/system11:33
* longsleep has no idea where it comes from11:33
fgimenezhi Chipaca, have a minute?11:39
dholbachmvo, can you (or somebody else) help with https://code.launchpad.net/~jdstrand/click-reviewers-tools/click-reviewers-tools.snappy1604/+merge/278218?11:55
=== verterok` is now known as verterok
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
Chipacajdstrand_: tyhicks: ping about snapd and ACLs12:46
Chipacawell, not ACLs, but permissions on the unix socket and SO_PEERCRED12:48
=== pixel__ is now known as pi||aw
mvodholbach: I have a look after the meeting, thanks12:59
=== bigcat_ is now known as bigcat
longsleepChipaca: 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 installed13:00
mvolongsleep: do you install something that has a service duing your u-d-f run?13:01
longsleepmvo: yes13:01
longsleepmvo: the oem snap has several snaps as built-in13:02
mvolongsleep: I think there is a bug in u-d-f13:02
longsleepmvo: when updating those, the old systemd service gets not removed and recreated on boot13:02
longsleepmvo: yeah that makes sense, though where does u-d-f store the information so the service can actually be recreated13:02
dholbachmvo, cool, thanks13:07
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/fchown3213:21
tyhicksChipaca: hey - I need some more context as I don't know if I've heard anything about that yet14:39
Chipacatyhicks: you probably haven't :)14:40
Chipacatyhicks: you remember snapd, the snappy daemon that runs as root, that you connect to over a unix socket?14:40
tyhicksChipaca: yep14:40
Chipacatyhicks: that socket is 0600 root:root right now14:40
Chipacatyhicks: wanting to relax that so regular users can connect14:41
Chipacatyhicks: so, server uses SO_PEERCREDS on the socket to determine uid, deny access to privileged ops to non-privileged users14:41
Chipacatyhicks: would like you or jamie to go over what/how we're doing that before actually lowering the 060014:42
tyhicksChipaca: is there a MP?14:42
Chipacatyhicks: the code that does SO_PEERCRED is already in master14:43
Chipacatyhicks: 1 sec and i'll point you at the relevant file itself14:43
Chipacatyhicks: https://github.com/ubuntu-core/snappy/blob/master/daemon/ucrednet.go14:44
tyhicksChipaca: ack, I should be able to have a look in a day or two14:44
Chipacatyhicks: that's the wrapper that knows about SO_PEERCRED and uses it to get the uid for unix connections14:44
tyhicks(maybe today)14:44
Chipacatyhicks: and then https://github.com/ubuntu-core/snappy/blob/master/daemon/daemon.go#L67 checks things before allowing access14:45
Chipacatyhicks: it's a rather hackish first pass that stuffs the uid in the RemoteAddr of the transfer, but modulo that it seems sane to me14:46
Chipacatyhicks: yeh, no hurry14:47
Chipacawell, no hurry beyond the usual :-)14:47
rickspencer3mvo, 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.0415:38
mvorickspencer3: 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 testing15:39
=== Ursinha_ is now known as Ursinha
longsleepso, 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 :/15:57
Chipacalongsleep: 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 though16:00
ogra_s/for xenial//16:01
longsleepChipaca: 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:01
longsleepChipaca: i have looked and looked but seem unable to find out how these files are generated / where they come from :/16:02
Chipacalongsleep: 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:03
longsleepChipaca: 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 again16:04
longsleepChipaca: it is the same problem for all services installed via oem16:05
longsleepChipaca: on update, the old service gets removed fine. Then reboot and it is back (and fails to start)16:05
longsleepChipaca: what troubles me is that i seem to be unable to figure out where it comes from16:05
=== balloons_ is now known as balloons
Chipacalongsleep: could i see the output of 'sudo journalctl' on a reboot with these things happening?16:06
Chipacalongsleep: firstboot is the thing that might be doing that, but it shouldn't be running16:06
longsleepChipaca: sure16:07
Chipacaand ... yeah, it doesn't make sense16:07
longsleepChipaca: it says started firstboot setup every time16:09
longsleeplet me check when i remove the firstboot stamp and run it manually16:10
longsleepChipaca: no, removing the stamp and running snappy firstboot did not create the service file again16:11
longsleepChipaca: 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 header16:12
* Chipaca looks up phone numbers of exorcists16:12
longsleepChipaca: it is either copied from some place or created from some other tool16:12
Chipacalongsleep: ooh, nice16:12
Chipacaogra_: pingu16:12
ogra_yo yo16:12
Chipacaogra_: is there anything in initrd/early boot that could be copying a service file?16:13
longsleepIt also needs to copy it from some place, i have removed all locations below /writable where that file could be found16:13
* ogra_ checks something16:13
Chipacalongsleep: can you mount and see if it's in /etc *under* writable?16:14
=== jdstrand_ is now known as jdstrand
longsleepChipaca: mount what exactly?16:14
Chipacalongsleep: umm... system-a? partition #3 iirc16:14
Chipacalongsleep: on a brand new image16:15
longsleepChipaca: sure - hold on16:15
Chipacalongsleep: (or on a booted one, really)16:15
longsleepChipaca: brand new booted one - without upgrading?16:15
Chipacalongsleep: yep16:15
longsleepChipaca: flashing now, takes 70 seconds16:16
Chipacalongsleep: ok. just mounting the image locally would also work :-)16:16
longsleepChipaca: that would not be booted though16:16
Chipacaah, sorry i meant booting it or not shouldn't make a difference to that partition16:17
Chipacaalthough, having said that, if it _did_ make a difference that'd be interesting in and of itself16: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 boot16:17
ogra_and etc gets processed from initrd16:18
ogra_(remember, we had to move it because of races)16:18
longsleepfinally the mystery solved!16:18
ogra_well, the bug is that fragments from snaps are on the readonly partition16:18
ogra_that shouldnt be16:19
longsleepthat is the non booted image16:19
Chipacaso the bug is that those are getting created by snappy during the u-d-f unpack/install thing16:19
ogra_they would have to go into the writable space16:20
longsleepi see - so this needs fixing in u-d-f16:20
ogra_since they are from snaps :)16:20
Chipacalongsleep: in snappy, actually16:20
ogra_(all of the snaps shuld go into the writable space in fact)16:20
longsleepChipaca: right16:20
Chipaca(u-d-f calls into snappy)16:20
longsleepChipaca: so add a flag or something, similar to the existing ones16:20
Chipacaflag already exists16:21
ogra_Chipaca, but if udf doesnt set up the mounting in a way that the snap bits land in writable places you have lost16:21
ogra_not necessarily a snappy bug imho16:21
Chipacaogra_: the service files should not be created at udf time; firstboot creates them16:21
longsleepthat would be easy to fix16:21
longsleepso for testing, i could remove the snap services from system-a and then do a boot16:22
Chipacalongsleep: yep16:22
* longsleep gives it a try16:23
ogra_Chipaca, aha ... nontheless, snap fragments should not live in the readonly rootfs16:23
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 up16:24
ogra_(i can be wrong indeed ... just guessing)16:25
longsleepwell, i removed the service files before firstboot, but firstboot did not create them16:25
longsleepChipaca: 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 loaded16:27
* Chipaca forgot how to emoticon16:27
longsleepWhere do you want to have the bug for this? github snappy or udf on launchpad?16:28
Chipacasergiusens: mvo: ping16:28
Chipacalongsleep: gimme a sec16:28
Chipacaso the easy way would be to hack udf to set things up properly16:29
Chipacai 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
Chipacabut there might be a reason not to do it this way16:29
longsleepChipaca: yeah, i guess we can do that and somehow move the things to writable16:29
Chipacahence me pinging mvo and sergiusens :-)16:30
Chipacalongsleep: 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:30
ogra_+1 for firstboot, that is where it belongs16:31
longsleepChipaca: so the other cruft in there should stay readonly ?16:31
longsleepogra_: yes, though that is unlikely to happen for 15.04 right?16:32
ogra_yeah, for that the hack might be a better approach16:32
sergiusensChipaca, the plan is to move it to firstboot16:35
sergiusensChipaca, if you care to create the PR for it, great ;-)16:35
ogra_the PR ?16:35
sergiusensogra_, pull request16:36
ogra_event planning ? cheerleaders, free food and flyers ? as in public relations ?16:36
ogra_aahh !16:36
sergiusensChipaca, 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 thing16:36
ogra_isnt that what we do on the phone ?16:37
ogra_(for custom tarballs)16:37
ogra_jdstrand, i assume you missed my ping from this morning ?16:38
sergiusensogra_, no; sadly no16:38
sergiusensunless it changed recently16:38
ogra_oh, i thought we did16:39
ogra_we really should :)16:39
Chipacasergiusens: for 15.04 also?16:40
mvoChipaca: 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/22616:40
mvoChipaca: 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:40
Chipacano no16:41
Chipacamy idea was *activating* them on first boot16:41
Chipacanot installing them16:41
Chipacain squashfs world that might be the same thing tho :-)16:41
Chipacabut in 15.04 having the unpack done at build time, and the activation at first boot, seems sane and should be easily doable16:42
Chipacabut i don't know if we want to, and if there is going to be a release of this16:42
Chipacahence, calling you16:42
ogra_well, we didnt stop doing monthlies for 15.04, did we ?16:43
ogra_to have the images pick up -security and -updates16:43
* Chipaca waits for mvo to confirm that16:45
longsleepChipaca: to hack it, where exactly do the files need to go on the writable partition? i see a system-data folder there16:46
longsleepChipaca: create etc/systemd/system in there ?16:47
mvoChipaca: 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:47
mvolongsleep, Chipaca: I need to run very soon to play hockey, however I'm happy to discuss this further tonight/tomorrow16:48
ogra_mvo, we'll need to sit down tomorrow too to talk about allsnaps and the build system16:48
Chipacai'll look at getting a branch up with this16:48
Chipacaalso, we need to get edge working on arm again16:48
mvoogra_: sure16:48
Chipacaand plan the next monthly 1504 (which i think we've slipped, unless time has done its usually stretchy snappy thing)16:49
mvoChipaca: yeah, no idea about the test failure right now :/ still need to investigate on a porter machine16:49
longsleepmvo: 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.0416:49
Chipacamvo: blame ogra_, then he'll fix it :-p16:49
longsleepmvo: 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 well16:50
ogra_Chipaca, heh, ask davmor2 ... that only works sometimes16:50
Chipacalongsleep: i can't be sure offhand. easiest way would be to see on upgraded machine what /writable looks like16:50
longsleepChipaca: good idea thanks16:50
mvolongsleep: aa, nice16:50
davmor2ogra_: no it works all the time, you just go blame the right person :D16:50
longsleepups :)16:53
rickspencer3ogra_, are there steps I can follow to make a rolling 16.04 rpi2 image today?16:55
Chipacarickspencer3: u-d-f doesn't work?16:58
rickspencer3Chipaca, I did not say that, I was looking for documentation16:58
ogra_rickspencer3, once sec i can give you a cmdline (the rpi püage needs updating for that)16:59
longsleepChipaca: ok i got scripting which fixes the problem: http://paste.ubuntu.com/13579233/17:02
longsleepChipaca: i think i can add that as a post process step to our image builder17:02
ogra_rickspencer3, sudo ubuntu-device-flash core rolling --channel edge --oem pi2.canonical --enable-ssh --device raspi2_armhf --output raspi2-rolling.img18:19
ogra_(sorry, i had not forotten you :) )18:19
ogra_(and ignore the moaning about azure :) )18:19
=== JamesTai1 is now known as JamesTait
jdstrandChipaca: 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 then18:55
Chipacajdstrand: a'yup18:57
Chipacajdstrand: welcome back to the world of the living, and all that18:57
* rickspencer3 tries18:59
Chipacaogra_: unless you've uploaded a pi2 since the channels work, that needs to be pi2.canonical/stable19:03
ogra_Chipaca, really ? udf cares ?19:03
Chipacano, it doesn't care, which is why that works :-)19:03
ogra_ah :)19:04
Chipacait's just passing that on to the CPI REST API19:04
ogra_rickspencer3, ^^19:04
Chipacaand CPI cares. In fact that's all it cares about ;-)19:04
Chipacasudo ubuntu-device-flash core rolling --channel edge --oem pi2.canonical/stable --enable-ssh --device raspi2_armhf --output raspi2-rolling.img19:04
Chipaca^ seems to work19:04
Chipacathat /stable is a temporary workaround until we get things into the edge channel itself19:05
* rickspencer3 tries again ;)19:05
* rickspencer3 happily kicks off his "azure" image19:06
rickspencer3ogra_, Chipaca seemed like it downloaded the parts and built the image quite quickly19:08
* rickspencer3 prepares to dd19:08
rickspencer3ogra_, just dd it to sbx as per usual, right?19:08
ogra_all the same for all images :)19:08
* rickspencer3 dds and waits19:10
Chipacahttp://people.canonical.com/~john/wow-so-peercred-much-access-levels.gif btw19:28
Chipacatyhicks: ^ might be relevant (or not)19:29
tyhicksChipaca: that's showing that the access checks aren't working as expected?19:34
Chipacatyhicks: no, it's showing that they are19:34
tyhicksah, right19:35
Chipacatyhicks: in retrospect i should have paused before hitting enter on 'sudo !!'19:35
Chipacaassuming that is what tripped you up :)19:35
tyhicksopening up the socket to be world read/write today means that root is still required19:36
tyhicksyes, I think that is what tripped me up19:36
Chipacatyhicks: root is still required <- for privileged operations you mean?19:37
sandGorgonhey 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 snappy19:39
ChipacasandGorgon: not an ISO. What are you wanting to play _on_?19:40
tyhicksChipaca: yes - your gif is showing that root is required for privileged operations even though anyone can write to the socket - correct?19:40
Chipacatyhicks: correct19:40
tyhicksgot it19:40
sergiusenselopio, do you feel good about releaseing current master as 0.6?19:41
Chipacatyhicks: didn't create the gif just for you, but thought it might be useful for you as well19:41
ChipacasandGorgon: 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 that19:42
sandGorgonChipaca, 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:42
ChipacasandGorgon: no, it does not sound stupid19:43
tyhicksChipaca: it will be helpful - thanks!19:43
ChipacasandGorgon: 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 same19:44
ChipacasandGorgon: i don't know how far along those plans are, though19:45
sandGorgonChipaca, "Ubuntu 16.04 LTS will be able to run Snappy packages19:48
sandGorgonWill 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
sandGorgonI 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:48
lotuspsychjesandGorgon: install xenial development branch and apt-cache search snappy19:49
lotuspsychjeand start fool around19:49
ChipacasandGorgon: yes, snappy packages, but not a snappy system19:49
sandGorgonlotuspsychje, will do ;)19:49
lotuspsychjesandGorgon: ive also tested unity8 on xenial19:55
lotuspsychjesandGorgon: also early stage now, so it looks pretty much like the phone version19:55
sandGorgonlotuspsychje, oh.. is it usable ?19:55
lotuspsychjesandGorgon: yes, mouse support, browsing19:56
sandGorgonlotuspsychje, ah ok.. i'll survive probably (P.S. im more of a gnome guy)19:56
lotuspsychjesandGorgon: then test the ubuntu-gnome xenial development branch19:58
sandGorgonlotuspsychje, that's what's downloading right now19:58
sergiusenselopio, https://github.com/ubuntu-core/snapcraft/pull/12720:09
jdstrandsergiusens: catching up on irc backscroll from holiday22: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] failed22:03
jdstrandsergiusens: 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:04
sergiusensjdstrand, I haven't looked too much into it, it is just related to https://bugs.launchpad.net/snapcraft/+bug/151925122:07
ubottuLaunchpad bug 1519251 in Snapcraft "Step copying .snap during 'snapcraft run' fails" [Undecided,Incomplete]22:07
jdstrandsergiusens: based on the sc-filtergen denial, the package yaml is using 'security-template: network-status'. It shouldn't do that22:13
jdstrandChipaca: 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 them22:16
tyhicksjdstrand: yes, I'm going to review the code22:19
tyhicks(card already created)22:19
jdstrandogra_: 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 user22:20
jdstrandogra_: 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 access22:21
jdstrandogra_: 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 to22:22
jdstrandogra_: 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 too22:24
jdstrandogra_: 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 interactions22:25
jdstrandso proceeding with caution there. but as mentioned, the seccomp arg filtering alone will likely fix the obstacle you are facing22:26
jdstrand(with the accompanying policy updates)22:26
jdstrandtyhicks: thanks22:26
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:28
jdstrandogra_: 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
jdstrandwhat are you putting in that config file?22:30
jdstrandwe 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 source22:31
ogra_i indeed dont put a user into that config file ... interesting fact is that lighttpd doesnt complain about fchown on amd6422:32
jdstrandogra_: is this a xenial system?22:32
ogra_amd64 is 15.04 edge ... armhf is xenial edge22:32
jdstrandogra_: on the xenial system, you can do the security-override method to unblock you while you investigate. eg:22:33
jdstrand  - name: foo22:33
jdstrand    security-override:22:33
ogra_i use lighttpd's webdav module ... i guess that links in some sqlite stuff or so22:33
jdstrand      syscalls: [ fchown32, chown, ... ]22:33
jdstrandand sqlite is doing the chown to root unconditionally to root22:33
ogra_yeah, i had that working at some point (and then threw everything away and started to patch the apps :P )22:33
ogra_so it is just a pointless syscall22:34
ogra_but it is as pointless that we block it imho22:34
jdstrandwell, I don't know about that22:35
ogra_given you cant chown anything outside of your confinement22:35
jdstrandI mentioned interactions22:35
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 remotely22:37
ogra_i was wondering if there is any way to protect us from such things22:38
jdstrandogra_: 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 them22:39
ogra_oh, so you want to do some extrausers magic on a per-snap base ?22:40
jdstrandthe easiest thing we can do which everyone already understands is allow for opt-in app ids22:40
jdstrandeg (and this is otoh, not designed or talked about beyond that thread and a couple of conversations):22:40
jdstrandname: foo22:40
jdstrand  - name: bar22:40
jdstrand    app-user: true22:41
jdstrandthen on install, that create the foo_bar user22:41
jdstrandthat is a sort of 'system' user in that it is passwordless, etc22:41
jdstrandthen the seccomp policy allows chowning to that user, etc22:41
jdstrandthere are other ways to do that22:42
jdstrandbut the basic idea is come up with something that namespaces the users to the package name22:42
ogra_i wonder if we couldnt teach libnss-extrausers to accept something like a passwd.d/ dir where snaps could drop their snippets22:42
jdstrands/snaps/snappy install/ :)22:42
jdstrandapp-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, etc22:43
jdstrandanyway, 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 input22:44
jdstrandmaybe this is something we can discuss at the upcoming sprint if there is time22:46
ogra_the feb. one you mean ? yeah22:47
jdstrandno, the one I am going to next week :)22:47
jdstrandbut sometime this cycle, sure22:47
jdstrandbeuno, 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
jdstrandbeuno, pindonga: basically, I don't want it hitting on the weekend or while I am sprinting in case I need to react quickly to something23:06
=== retrack is now known as Guest23314
ogra_jdstrand, oh, btw ... if i put the above into my snapcraft.yaml i get23:36
ogra_Issues while validating snapcraft.yaml: 'apparmor' is a required property23:36
ogra_seems security-override wants an apparmor line too23:36
jdstrandogra_: I think snapcraft needs to be updated for the new 16.04 yaml23:36
jdstrandsergiusens: I mentioned this elsewhere, but fyi ^23:37
jdstrandogra_: oh, is that click review tools?23:37
jdstrandogra_: yes, there is an MP about to land for that23:37
ogra_might be ... i get it on "snapcaft clean"23:37
jdstrandogra_: can you paste the output?23:37
ogra_well, that was all output23:38
ogra_root@localhost:/upnp-server# snapcraft clean23:38
ogra_Issues while validating snapcraft.yaml: 'apparmor' is a required property23:38
jdstrandsergiusens: fyi, not sure if snapcraft needs to be updated or not (just fyi)23:38
jdstrandthat sounds like it does23:38
* ogra_ still doesnt get why lighttpd behaves different on armhf vs amd64 ... there is no fchown32 call on amd64 it seems 23:40
jdstrandyeah, there will be different syscalls between those23:40
ogra_well, different, sure ... but having the call on one arch and not on the other ?23:41
jdstrandfchown and fchown32 are maybe what you need23:41
jdstrandyeah, that is common23:41
jdstrandor at least, not uncommon23:42
ogra_really ?23:42
jdstrandI didn't know that either til having to look at all these23:42
ogra_oh man23:49
* ogra_ slaps forehead 23:49
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_ blushes23:50

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!