=== 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 [08:35] good morning === 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 [10:20] 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] i think we need some mechanism to make the package know when it needs to run any confi migration scripts [10:22] *config [10:22] ogra_: it should be available via SNAP_VERSION [10:22] ah, thanks ! [10:22] ogra_: hm, there was discussion about providing a native hook for this from snappy itself [10:23] Good morning all; happy Monday, and happy Computer Security Day! 😃 [10:23] 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] geez, "snappy build" is amazingly slow o armhf :/ [10:27] *on [10:27] 11min for a package that takes 2min to build on amd64 [10:30] 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] it should be readonly mounted after boot ... but nothing else [10:32] /writable/cache/system that is [10:33] ogra_: yes it is mounted ro there, but something seems to copy all the files in there on boot [10:33] ogra_: could that be? [10:33] i dont think so [10:33] it is your "other" readonly partition [10:34] right - this is very strange [10:34] i delete a file from /etc/systemd/service and disable the service with systemctl as well, reboot then it is there again [10:34] probably some generator ? [10:35] though even that should respect that you disabled it [10:35] the service comes from a snap - snap is still installed as newer version [10:35] the version the service gets generated for is not on the disk - at least i cannot find it [10:36] 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] that sounds definitely like a bug [10:37] ogra_: yeah, though i was unable to figure out how that even happens yet [10:41] 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] longsleep, i guess the issue is that it is in /writable/cache/system/etc/systemd/system at all ... [10:43] thats a readonly system ... no snap should be able to put anything there ever [10:43] ogra_: true, but those are put there by u-d-f i think [10:44] ogra_: the snaps are preinstalled with the oem snap [10:44] hmm, sounds wrong to me to put them in the readonly partition [10:45] yeah, they will never go away [10:45] i would be fine with that, but how are they cloned on boot? [10:45] i mean that causes the problem after all [10:49] ogra_: i think it is synced in the initrd [10:51] longsleep, i wouldnt see how [10:51] ogra_: well, there is some code in the ubuntu-core-rootfs of the initrd which does some copying [10:51] yes [10:51] ogra_: maybe i use ancient version again [10:51] one sec [10:52] bah, i was hoping for a wrong setting in /etc/system-image/writable-paths ... but seems the cache path is actually hardcoded [10:53] hmm, k ... [10:53] the initrd doesnt mount it at all [10:54] if [ -n "$other" ]; then [10:54] echo "$other /writable/cache/system auto defaults,ro 0 0" >> "$fstab" [10:54] fi [10:54] right [10:54] thats all it does ... right before run-init [10:54] so if there is any syncing thats not happening in the initrd [10:54] maybe it runs into one of the other conditions which do cp -A [10:55] 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] well, there must be some systemd unit that copies it [10:56] when processing fstab [10:56] ok let me check if i can find something there === vrruiz_ is now known as rvr === chihchun is now known as chihchun_afk [11:33] 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] hi Chipaca, have a minute? [11:55] mvo, can you (or somebody else) help with https://code.launchpad.net/~jdstrand/click-reviewers-tools/click-reviewers-tools.snappy1604/+merge/278218? === verterok` is now known as verterok [12:46] Nov 30 13:44:32 aleph2 systemd[1]: Starting minidlna DLNA server... [12:46] 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] Nov 30 13:44:32 aleph2 systemd[1]: Reloading. [12:46] woah [12:46] jdstrand_: tyhicks: ping about snapd and ACLs [12:48] well, not ACLs, but permissions on the unix socket and SO_PEERCRED === pixel__ is now known as pi||aw [12:59] dholbach: I have a look after the meeting, thanks === bigcat_ is now known as bigcat [13:00] 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] longsleep: do you install something that has a service duing your u-d-f run? [13:01] mvo: yes [13:02] mvo: the oem snap has several snaps as built-in [13:02] longsleep: I think there is a bug in u-d-f [13:02] mvo: when updating those, the old systemd service gets not removed and recreated on boot [13:02] mvo: yeah that makes sense, though where does u-d-f store the information so the service can actually be recreated [13:07] mvo, cool, thanks [13:21] 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] Chipaca: hey - I need some more context as I don't know if I've heard anything about that yet [14:40] tyhicks: you probably haven't :) [14:40] tyhicks: you remember snapd, the snappy daemon that runs as root, that you connect to over a unix socket? [14:40] Chipaca: yep [14:40] tyhicks: that socket is 0600 root:root right now [14:41] tyhicks: wanting to relax that so regular users can connect [14:41] tyhicks: so, server uses SO_PEERCREDS on the socket to determine uid, deny access to privileged ops to non-privileged users [14:41] ok [14:42] tyhicks: would like you or jamie to go over what/how we're doing that before actually lowering the 0600 [14:42] Chipaca: is there a MP? [14:43] tyhicks: the code that does SO_PEERCRED is already in master [14:43] tyhicks: 1 sec and i'll point you at the relevant file itself [14:44] tyhicks: https://github.com/ubuntu-core/snappy/blob/master/daemon/ucrednet.go [14:44] Chipaca: ack, I should be able to have a look in a day or two [14:44] tyhicks: that's the wrapper that knows about SO_PEERCRED and uses it to get the uid for unix connections [14:44] (maybe today) [14:45] tyhicks: and then https://github.com/ubuntu-core/snappy/blob/master/daemon/daemon.go#L67 checks things before allowing access [14:46] ok [14:46] 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] transport* [14:47] tyhicks: yeh, no hurry [14:47] well, no hurry beyond the usual :-) [15:38] 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] 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] ack === Ursinha_ is now known as Ursinha [15:57] 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] longsleep: what are the files that won't die? [16:00] mvo, no, i didnt, i would like us to eventually produce whole images for xenial in an automated way though [16:01] s/for xenial// [16:01] 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] Chipaca: i have looked and looked but seem unable to find out how these files are generated / where they come from :/ [16:03] 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] 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] Chipaca: it is the same problem for all services installed via oem [16:05] Chipaca: on update, the old service gets removed fine. Then reboot and it is back (and fails to start) [16:05] Chipaca: what troubles me is that i seem to be unable to figure out where it comes from === balloons_ is now known as balloons [16:06] longsleep: could i see the output of 'sudo journalctl' on a reboot with these things happening? [16:06] longsleep: firstboot is the thing that might be doing that, but it shouldn't be running [16:07] Chipaca: sure [16:07] and ... yeah, it doesn't make sense [16:09] Chipaca: it says started firstboot setup every time [16:10] let me check when i remove the firstboot stamp and run it manually [16:11] Chipaca: no, removing the stamp and running snappy firstboot did not create the service file again [16:11] phew [16:12] 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] Chipaca: it is either copied from some place or created from some other tool [16:12] longsleep: ooh, nice [16:12] ogra_: pingu [16:12] yo yo [16:13] ogra_: is there anything in initrd/early boot that could be copying a service file? [16:13] no [16:13] hmm [16:13] well [16:13] 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] longsleep: can you mount and see if it's in /etc *under* writable? === jdstrand_ is now known as jdstrand [16:14] Chipaca: mount what exactly? [16:14] longsleep: umm... system-a? partition #3 iirc [16:15] longsleep: on a brand new image [16:15] Chipaca: sure - hold on [16:15] longsleep: (or on a booted one, really) [16:15] Chipaca: brand new booted one - without upgrading? [16:15] longsleep: yep [16:16] Chipaca: flashing now, takes 70 seconds [16:16] longsleep: ok. just mounting the image locally would also work :-) [16:16] Chipaca: that would not be booted though [16:17] ah, sorry i meant booting it or not shouldn't make a difference to that partition [16:17] although, having said that, if it _did_ make a difference that'd be interesting in and of itself [16:17] 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] ah [16:18] and etc gets processed from initrd [16:18] (remember, we had to move it because of races) [16:18] finally the mystery solved! [16:18] well, the bug is that fragments from snaps are on the readonly partition [16:19] that shouldnt be [16:19] /media/longsleep/system-a/etc/systemd/system/spreedbox-led_gnatsd_0.0.6-1.service [16:19] that is the non booted image [16:19] right [16:19] so the bug is that those are getting created by snappy during the u-d-f unpack/install thing [16:19] yeah [16:20] they would have to go into the writable space [16:20] i see - so this needs fixing in u-d-f [16:20] since they are from snaps :) [16:20] longsleep: in snappy, actually [16:20] (all of the snaps shuld go into the writable space in fact) [16:20] Chipaca: right [16:20] (u-d-f calls into snappy) [16:20] Chipaca: so add a flag or something, similar to the existing ones [16:20] yep [16:21] flag already exists [16:21] InhibitHooks [16:21] 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] not necessarily a snappy bug imho [16:21] ogra_: the service files should not be created at udf time; firstboot creates them [16:21] that would be easy to fix [16:22] so for testing, i could remove the snap services from system-a and then do a boot [16:22] right? [16:22] longsleep: yep [16:23] * longsleep gives it a try [16:23] Chipaca, aha ... nontheless, snap fragments should not live in the readonly rootfs [16:24] 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] (i can be wrong indeed ... just guessing) [16:25] well, i removed the service files before firstboot, but firstboot did not create them [16:27] 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] :'-( [16:27] * Chipaca forgot how to emoticon [16:28] Where do you want to have the bug for this? github snappy or udf on launchpad? [16:28] sergiusens: mvo: ping [16:28] longsleep: gimme a sec [16:29] so the easy way would be to hack udf to set things up properly [16:29] 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] but there might be a reason not to do it this way [16:29] Chipaca: yeah, i guess we can do that and somehow move the things to writable [16:30] hence me pinging mvo and sergiusens :-) [16:30] 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] +1 for firstboot, that is where it belongs [16:31] Chipaca: so the other cruft in there should stay readonly ? [16:32] ogra_: yes, though that is unlikely to happen for 15.04 right? [16:32] yeah, for that the hack might be a better approach [16:35] Chipaca, the plan is to move it to firstboot [16:35] Chipaca, if you care to create the PR for it, great ;-) [16:35] the PR ? [16:36] ogra_, pull request [16:36] event planning ? cheerleaders, free food and flyers ? as in public relations ? [16:36] aahh ! [16:36] 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] +1 [16:37] isnt that what we do on the phone ? [16:37] (for custom tarballs) [16:38] jdstrand, i assume you missed my ping from this morning ? [16:38] ogra_, no; sadly no [16:38] unless it changed recently [16:39] oh, i thought we did [16:39] we really should :) [16:40] sergiusens: for 15.04 also? [16:40] 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] 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] no no [16:41] no? [16:41] my idea was *activating* them on first boot [16:41] not installing them [16:41] in squashfs world that might be the same thing tho :-) [16:42] 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] but i don't know if we want to, and if there is going to be a release of this [16:42] hence, calling you [16:43] well, we didnt stop doing monthlies for 15.04, did we ? [16:43] to have the images pick up -security and -updates [16:45] * Chipaca waits for mvo to confirm that [16:46] 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] Chipaca: create etc/systemd/system in there ? [16:47] 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] longsleep, Chipaca: I need to run very soon to play hockey, however I'm happy to discuss this further tonight/tomorrow [16:48] mvo, we'll need to sit down tomorrow too to talk about allsnaps and the build system [16:48] i'll look at getting a branch up with this [16:48] also, we need to get edge working on arm again [16:48] ogra_: sure [16:49] and plan the next monthly 1504 (which i think we've slipped, unless time has done its usually stretchy snappy thing) [16:49] Chipaca: yeah, no idea about the test failure right now :/ still need to investigate on a porter machine [16:49] 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] mvo: blame ogra_, then he'll fix it :-p [16:50] 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] Chipaca, heh, ask davmor2 ... that only works sometimes [16:50] longsleep: i can't be sure offhand. easiest way would be to see on upgraded machine what /writable looks like [16:50] Chipaca: good idea thanks [16:50] longsleep: aa, nice [16:50] ogra_: no it works all the time, you just go blame the right person :D [16:53] sync [16:53] ups :) [16:55] ogra_, are there steps I can follow to make a rolling 16.04 rpi2 image today? [16:58] rickspencer3: u-d-f doesn't work? [16:58] Chipaca, I did not say that, I was looking for documentation [16:59] :) [16:59] rickspencer3, once sec i can give you a cmdline (the rpi püage needs updating for that) [17:02] Chipaca: ok i got scripting which fixes the problem: http://paste.ubuntu.com/13579233/ [17:02] Chipaca: i think i can add that as a post process step to our image builder [18:19] rickspencer3, sudo ubuntu-device-flash core rolling --channel edge --oem pi2.canonical --enable-ssh --device raspi2_armhf --output raspi2-rolling.img [18:19] (sorry, i had not forotten you :) ) [18:19] (and ignore the moaning about azure :) ) === JamesTai1 is now known as JamesTait [18:55] 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] jdstrand: a'yup [18:57] jdstrand: welcome back to the world of the living, and all that [18:59] * rickspencer3 tries [19:03] ogra_: unless you've uploaded a pi2 since the channels work, that needs to be pi2.canonical/stable [19:03] Chipaca, really ? udf cares ? [19:03] no, it doesn't care, which is why that works :-) [19:04] ah :) [19:04] it's just passing that on to the CPI REST API [19:04] rickspencer3, ^^ [19:04] and CPI cares. In fact that's all it cares about ;-) [19:04] sudo ubuntu-device-flash core rolling --channel edge --oem pi2.canonical/stable --enable-ssh --device raspi2_armhf --output raspi2-rolling.img [19:04] ^ seems to work [19:04] oh [19:05] 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] ogra_, Chipaca seemed like it downloaded the parts and built the image quite quickly [19:08] * rickspencer3 prepares to dd [19:08] good [19:08] ogra_, just dd it to sbx as per usual, right? [19:08] yeah [19:08] all the same for all images :) [19:10] * rickspencer3 dds and waits [19:28] http://people.canonical.com/~john/wow-so-peercred-much-access-levels.gif btw [19:29] tyhicks: ^ might be relevant (or not) [19:34] Chipaca: that's showing that the access checks aren't working as expected? [19:34] tyhicks: no, it's showing that they are [19:35] ah, right [19:35] tyhicks: in retrospect i should have paused before hitting enter on 'sudo !!' [19:35] assuming that is what tripped you up :) [19:36] opening up the socket to be world read/write today means that root is still required [19:36] yes, I think that is what tripped me up [19:37] tyhicks: root is still required <- for privileged operations you mean? [19:39] 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] sandGorgon: not an ISO. What are you wanting to play _on_? [19:40] Chipaca: yes - your gif is showing that root is required for privileged operations even though anyone can write to the socket - correct? [19:40] tyhicks: correct [19:40] got it [19:41] elopio, do you feel good about releaseing current master as 0.6? [19:41] tyhicks: didn't create the gif just for you, but thought it might be useful for you as well [19:42] 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] 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] sandGorgon: no, it does not sound stupid [19:43] Chipaca: it will be helpful - thanks! [19:44] 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] sandGorgon: i don't know how far along those plans are, though [19:48] Chipaca, "Ubuntu 16.04 LTS will be able to run Snappy packages [19:48] 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] 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] sandGorgon: install xenial development branch and apt-cache search snappy [19:49] and start fool around [19:49] sandGorgon: yes, snappy packages, but not a snappy system [19:49] lotuspsychje, will do ;) [19:55] sandGorgon: ive also tested unity8 on xenial [19:55] sandGorgon: also early stage now, so it looks pretty much like the phone version [19:55] lotuspsychje, oh.. is it usable ? [19:56] sandGorgon: yes, mouse support, browsing [19:56] lotuspsychje, ah ok.. i'll survive probably (P.S. im more of a gnome guy) [19:58] sandGorgon: then test the ubuntu-gnome xenial development branch [19:58] lotuspsychje, that's what's downloading right now [20:09] elopio, https://github.com/ubuntu-core/snapcraft/pull/127 [22:03] sergiusens: catching up on irc backscroll from holiday [22:03] < 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] 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] jdstrand, I haven't looked too much into it, it is just related to https://bugs.launchpad.net/snapcraft/+bug/1519251 [22:07] Launchpad bug 1519251 in Snapcraft "Step copying .snap during 'snapcraft run' fails" [Undecided,Incomplete] [22:13] sergiusens: based on the sc-filtergen denial, the package yaml is using 'security-template: network-status'. It shouldn't do that [22:14] s/denial/error/ [22:16] 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] jdstrand: yes, I'm going to review the code [22:19] (card already created) [22:20] 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] 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] 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] 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] 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] so proceeding with caution there. but as mentioned, the seccomp arg filtering alone will likely fix the obstacle you are facing [22:26] (with the accompanying policy updates) [22:26] tyhicks: thanks [22:28] jdstrand, well, lighttpd and sqlite both only use fchown when they are run as root to chown files to the right UIDs ... [22:28] and as it happens i'm just assembling something that uses both :) [22:30] 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] ("to the right UIDs" typically to the UIDs defined in the config file) [22:30] what are you putting in that config file? [22:31] we don't have per-app user ids yet (see mailing list) [22:31] well, i'm not really clear what lighttpd does, i cant find any trace of "chown" in the source [22:32] i indeed dont put a user into that config file ... interesting fact is that lighttpd doesnt complain about fchown on amd64 [22:32] ogra_: is this a xenial system? [22:32] amd64 is 15.04 edge ... armhf is xenial edge [22:33] ogra_: on the xenial system, you can do the security-override method to unblock you while you investigate. eg: [22:33] services: [22:33] - name: foo [22:33] security-override: [22:33] i use lighttpd's webdav module ... i guess that links in some sqlite stuff or so [22:33] syscalls: [ fchown32, chown, ... ] [22:33] perhaps [22:33] and sqlite is doing the chown to root unconditionally to root [22:33] yeah, i had that working at some point (and then threw everything away and started to patch the apps :P ) [22:34] right [22:34] so it is just a pointless syscall [22:34] but it is as pointless that we block it imho [22:35] well, I don't know about that [22:35] given you cant chown anything outside of your confinement [22:35] I mentioned interactions [22:37] 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] s/spp/app/ [22:37] s/later/alter/ [22:38] i was wondering if there is any way to protect us from such things [22:39] 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] oh, so you want to do some extrausers magic on a per-snap base ? [22:40] the easiest thing we can do which everyone already understands is allow for opt-in app ids [22:40] eg (and this is otoh, not designed or talked about beyond that thread and a couple of conversations): [22:40] services: [22:40] wait [22:40] name: foo [22:40] services: [22:40] - name: bar [22:41] app-user: true [22:41] then on install, that create the foo_bar user [22:41] creates [22:41] hmm [22:41] that is a sort of 'system' user in that it is passwordless, etc [22:41] then the seccomp policy allows chowning to that user, etc [22:42] there are other ways to do that [22:42] but the basic idea is come up with something that namespaces the users to the package name [22:42] i wonder if we couldnt teach libnss-extrausers to accept something like a passwd.d/ dir where snaps could drop their snippets [22:42] s/snaps/snappy install/ :) [22:43] :) [22:43] 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] 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] right [22:46] maybe this is something we can discuss at the upcoming sprint if there is time [22:47] the feb. one you mean ? yeah [22:47] no, the one I am going to next week :) [22:47] ah [22:47] but sometime this cycle, sure [23:06] 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] 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 === retrack is now known as Guest23314 [23:36] jdstrand, oh, btw ... if i put the above into my snapcraft.yaml i get [23:36] Issues while validating snapcraft.yaml: 'apparmor' is a required property [23:36] seems security-override wants an apparmor line too [23:36] ogra_: I think snapcraft needs to be updated for the new 16.04 yaml [23:37] sergiusens: I mentioned this elsewhere, but fyi ^ [23:37] ogra_: oh, is that click review tools? [23:37] ogra_: yes, there is an MP about to land for that [23:37] might be ... i get it on "snapcaft clean" [23:37] ogra_: can you paste the output? [23:38] well, that was all output [23:38] root@localhost:/upnp-server# snapcraft clean [23:38] Issues while validating snapcraft.yaml: 'apparmor' is a required property [23:38] root@localhost:/upnp-server# [23:38] sergiusens: fyi, not sure if snapcraft needs to be updated or not (just fyi) [23:38] that sounds like it does [23:39] 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]