[00:12] ogra_: noice === chihchun_afk is now known as chihchun === bigcat_ is now known as bigcat === chihchun is now known as chihchun_afk [08:02] good morning [08:17] good morning [08:23] hey fgimenez, good morning! [08:24] ogra_: this armhf build failure is quite annoying, it takes forever to run the tests on a porter box [08:24] hi mvo! [08:27] mvo, btw with the new cloud resources in place we should redirect the github webhook, let me know when you have a minute and i'll send you the new ip [08:32] fgimenez: sure, I have a minute [08:32] fgimenez: trying to figure out an armhf build failure right now [08:36] mvo, once i finish fixing the snapd integration tests we should have green builds, i'll fire up builds every 15 minutes to check [08:37] fgimenez: sweet. and then we can add a user that leaves comments too, right? [08:39] mvo, yep, we should create a new github user and add it to the organization as collaborator, then add its credentials to jenkins, and that's it :) === chihchun_afk is now known as chihchun [10:10] jdstrand: could we add 'less' to the list of things we can exec when confined? [10:17] Good morning all! Happy Giving Tuesday, and happy Bifocals at the Monitor Liberation Day! 😃 [10:24] JamesTait: monitors had a liberation day, and bifocals were present, and it was an event that needs commemorating? [10:24] JamesTait: the mind is boggled [10:28] Chipaca, it's a tribute to those poor souls who wear bifocals and use a monitor daily, and keep bobbing their heads up and down trying to figure out which lens to use. [10:29] yeah. fear that day. [10:29] i wouldn't be able to look at the monitor with my head tilted, letting ideas settle around the clot [10:46] longsleep: ping [11:09] Chipaca: pong [11:13] Chipaca: i added a hack to u-d-f, moving the services to writable - i know it is crappy but works for now http://paste.ubuntu.com/13597040/ [11:14] longsleep: heh. i'm working on that right now (on the snappy side) [11:14] broke all the tests of course [11:14] Chipaca: you are moving the stuff to first boot now? [11:14] longsleep: the ping was to ask you for your oem package.yaml, if that was shareable [11:14] longsleep: yes [11:14] Chipaca: ok good [11:15] longsleep: making install not activate from u-d-f (u-d-f passes in a particular flag), then making firstboot activate them [11:15] Chipaca: uhm sure i can share the oem snap, though the snaps are not in the store [11:15] yep, no worries about that [11:16] and feel free to munge the names if they are sensitive [11:16] Chipaca: http://paste.ubuntu.com/13597081/ [11:16] just looking for a real-world example, as what i've got access to is either too bare, or theoretical [11:16] perfect [11:16] Chipaca: yeah, this is what we currently use === chihchun is now known as chihchun_afk [11:52] jdstrand, hi there, there is no schedule... which revno do you want to release? I'll do my best to get it out asap === chihchun_afk is now known as chihchun [12:01] hi Chipaca, ive got a question about http.chipaca [12:01] fgimenez: shoot [12:02] Chipaca, it doesn't let me send files http://paste.ubuntu.com/13597723/, am i doing it right? [12:03] Chipaca, this is the response with debug enabled http://paste.ubuntu.com/13597757/ [12:06] fgimenez: it can't read /tmp/pp, because it'll have its own private /tmp [12:06] fgimenez: two questions: [12:06] fgimenez: first, what's in /tmp/pp? [12:07] Chipaca, nothing, just touched it for trying, the real test tries to use a snap file from ADT_ARTIFACTS, under /tmp [12:08] Chipaca, i can try to move it to wherever http needs [12:08] fgimenez: would `cat /tmp/pp | sudo http.POST snapd:///1.0/packages` work? [12:09] otherwise, put it under $SNAP_APP_DATA_PATH [12:09] i.e., /var/lib/apps/http.chipaca/current/ [12:09] Chipaca, yep, works fine :) ok, i'll try putting it there, thanks! [12:10] pipes are easy from the shell, but tricky in a test, so [14:59] Chipaca, is it also possible to pass http a json string literal, as in http://paste.ubuntu.com/13600302/ ? [15:00] fgimenez: yes, but [15:03] fgimenez: https://github.com/jkbrzt/httpie#request-items [15:06] fgimenez: so in particular for doing a multi-config PUT, [15:07] gah. gimme a bit. [15:07] Chipaca: re less, sure [15:08] jdstrand: whee :-) [15:08] Chipaca: when do you need it? [15:08] jdstrand: less has exec-this-other-thing, but that'll just fail because confinement, right? [15:08] jdstrand: no hurry, backburner project needs it (or me reimplementing a pager in python ;-) ) [15:08] Chipaca: it will fail to exec the other thing, yes [15:09] * Chipaca will run it with that feature disable, because usability++, but still [15:11] fgimenez: sudo http.PUT snapd:///1.0/packages 'ubuntu-core.ubuntu:="config: {ubuntu-core: {autoupdate: true}}"' [15:11] fgimenez: note the quotes in the quotes [15:13] sergiusens, so you're landing 0.6 soon? :) [15:14] fgimenez: the thing on the right of the := is a json string literal (hence the double quotes there). Of YAML. [15:14] dholbach, yeah [15:14] not the nicest of things, but ¯\_(ツ)_/¯ [15:14] jdstrand, is there a cap I can use for capname="net_admin" on 15.04? [15:15] Chipaca, great, in my case 'ubuntu-core.ubuntu:="config: {basic-config.sideload: {key: value}}"' prevents the 400 and creates the operation, i'll put that into the test, thanks! [15:16] ummm [15:16] fgimenez: that should kinda not work [15:16] that is, the operation should fail [15:16] because ubuntu-core.ubuntu mismatch with basic-config.sideload [15:16] sergiusens, awesome :) [15:17] fgimenez: (yes, config is redundant like that; needs revamp) [15:18] Chipaca, yes i'm getting "invalid ubuntu-core configuration", ok, then 'basic-config.sideload:="config: {basic-config.sideload: {key: value}}"', right? [15:18] plars: are you here? [15:20] elopio: sort of, feeling pretty sick today. What's up? [15:20] Chipaca, yes, that works fine, thanks :) [15:20] plars: I need your help to collect the SPI output. But I can wait, lets talk tomorrow, get some rest. [15:20] plars: I hope you get better soon. [15:21] fgimenez: \o/ :) [15:21] sergiusens: yes. either network-admin or network-firewall [15:21] jdstrand, thanks [15:22] sergiusens: are you aware of 'sudo snappy-debug.security scanlog' :) [15:22] ? [15:22] elopio: no, it's fine. was this from a job that just ran? [15:22] jdstrand, I wasn't, no I am :-) [15:22] plars: latest ran yesterday midnight. Want me to run another one? [15:22] Chipaca: ok, you are getting less{,file,pipe} and more [15:23] jdstrand: whee :-) [15:24] mvo: do you have time to talk about the godd snap? [15:24] elopio: I think I found it, one sec [15:25] jdstrand, are all three suggestions to be followed? http://paste.ubuntu.com/13600633/ [15:26] sergiusens: no. pick one [15:26] jdstrand, I already put network-admin in there, which is why I ask [15:27] sergiusens: is that a new denial or a previous denial? [15:27] jdstrand, it is a fresh boot [15:28] sergiusens: I'm guessing that /var/lib/snappy/seccomp/profiles/gopaste.sideload_... doesn't reflect the change [15:28] elopio: yes [15:28] elopio: https://pastebin.canonical.com/145186/plain/ [15:28] sergiusens: or it didn't at the time it started [15:28] mvo: Kalnischkiesfile [15:29] sergiusens: check if setsockopt is in /var/lib/snappy/seccomp/profiles/gopaste.sideload_... [15:29] mvo: in https://mvogt.wordpress.com/2015/11/30/apt-1-1-released/ in english [15:29] jdstrand, it is not [15:29] elopio: that seems to be all that came through [15:30] sergiusens: how did you install the snap? [15:30] jdstrand, `snapcraft run` :-) [15:30] plars: so it's running! but being killed. [15:31] Chipaca: hm? did I misspell something somewhere? [15:31] Chipaca: in that blog post? [15:31] mvo: yes [15:31] mvo: I don't know if it's misspelt; it's just not very englishy [15:31] elopio: kick off another one and I'll see if it does anything different [15:31] sergiusens: what is in the generated meta/package.yaml on the device? [15:32] mvo: I hw-assigned /dev/null to the snapp but I am still getting: [15:32] godd.godd [15:32] /apps/godd.sideload/current/godd_1.0_amd64.snap /dev/null [15:32] failed to dd: open /proc/self/mountinfo: permission denied [15:32] what else should I give to the snap to be able to run the bin? [15:32] jdstrand, http://paste.ubuntu.com/13600718/ this file looks strange though [15:32] Chipaca: haha now I see what you mean, this is actually kind of funny [15:34] plars: triggered. [15:34] sergiusens: what is the version of ubuntu-core-security-seccomp on the device? === kickinz1_ is now known as kickinz1 [15:34] elopio: hm, can you he-assign /proc/self/mountinfo? just for fun and testing? [15:35] elopio: it needs this to prevent you from shooting yourself in the food [15:35] jdstrand, hah, hard to know given the dpkg cache is wiped [15:35] mvo, do you know? ^ [15:35] elopio: I think for this to be a proper snap it needs a customized appamor profile, i.e. it needs to be able to write to /dev/** by default [15:36] sergiusens: latest rolling? I can check on the builds. or what version of the image do you use? [15:36] mvo, 15.04 stable [15:36] sergiusens: we have the dpkg info on 15.04 :) [15:36] sergiusens: acutally, that shouldn't matter. snappy-debug.security looks at what is installed on the device and if it is suggesting network-admin, then network-admin should have it [15:36] mvo, oh right [15:38] sergiusens: how does snapcraft run work? is it just doing a snappy install of a generated snap or is it doing something else? [15:38] jdstrand, it scp's the snap and installs it [15:38] sergiusens: can you give me the snap? [15:38] jdstrand, with `snappy install` [15:38] jdstrand, sure [15:39] jdstrand, http://people.canonical.com/~sergiusens/snappy/gopaste_1.0_amd64.snap [15:39] mvo: I can't hw-assign mountinfo. It says invalid hardware device. [15:39] sergiusens: btw, you are almost certainly hitting https://bugs.launchpad.net/snappy/+bug/1465724 and don't actually need network-admin [15:39] Launchpad bug 1465724 in Snappy "net_admin apparmor denial when using Go" [High,Confirmed] [15:40] elopio: aha, indeed, there is a check for this [15:41] (snappy-debug.security should mention that, but you ran it after you added the cap I think) [15:41] elopio: hm, then we need to update the security profile of this to make it work on snappy itself. whats you use-case (just curious)? [15:42] mvo: there is a godd snap in the snapcraft examples. I want to run the binary and check the output. [15:42] jdstrand: is /proc/self/mountinfo unreadable for a reason? [15:42] jdstrand, for every snap I build I restart the vm though [15:43] * Chipaca is not trying to ddos jdstrand [15:43] unless the log persists, which I think it doesn't, it shouldn't be the root cause [15:43] mvo, we just want the examples in snapcraft to actually run and not just build ;-) [15:44] Chipaca: yes, it is an information leak [15:44] aww [15:44] sergiusens: I can confirm this. it is a bug in snappy-debug.security [15:44] mvo: so i guess godd needs fixing to not need that [15:45] jdstrand, how so? [15:45] sergiusens: it is suggesting network-admin and network-admin doesn't have setsockopt [15:46] sergiusens: use network-service or network-client [15:47] jdstrand, ah, thanks; will try and report back [15:47] sergiusens, elopio: let me look at this [15:48] oh heh [15:48] silly bug [15:48] fix is easy. here is the output: [15:48] Syscall: setsockopt [15:48] Suggestions: [15:48] * add 'setsockopt' to seccomp policy [15:48] * add one of 'network-client, network-firewall, network-service' to 'caps' [15:48] * add 'setsockopt' to seccomp file in 'security-policy' [15:48] thanks mvo [15:48] sergiusens: ^ [15:50] jdstrand, yay, no I have a defunct process, let's see why :-) [15:51] elopio: my bbb tests on rolling seem to be failing since last week when I was away also. Looks like the last one that passed was 237 [15:53] elopio: well, maybe... that one might be a fluke. Out of curiosity, do you have it saving your output to a location that you cleanup? or is it still a tmpdir? [15:54] plars: I'm using the pwd to put the resulting files, and mktemp -d to get the code. I delete the temp dir on exit. [15:55] elopio, sergiusens: sorry, looks like I can not easily fix it, snapcraft does not understand the new security-override syntax it seems [15:55] jdstrand, oh goodie, I now ran into the sqlite fchown issue ;-) [15:56] sergiusens: it appears that https://github.com/mvo5/godd/commit/38dfb37c34db7c1314ee1fe6a730c53565de9914 is making snapcraft unhappy [15:56] jdstrand, is that going to be allowed soon or should I fix it in the snap [15:56] how is it that everything is using sqlite all of a sudden... [15:56] elopio: well, there was no output from it that time, and the dir has already been cleaned up so I can't see anything useful from it [15:57] mvo: oh, I was thinking this was a bad snapcraft example because it wasn't showing anything useful. But now with the security override it's interesting. [15:57] sergiusens: it should be fixed in the snap or someone should fix it in the archive [15:57] elopio: all I can see is that it exited with rc=1 [15:57] mvo, notice that this version of snapcraft does not play nice at all with 16.04 syntax [15:57] plars: but looking at this output you pasted, it seems that something is killing my script, right? [15:58] elopio: not unless you are, or it times out and spi is killing it or something [15:58] elopio: that last one exited with the same rc [15:59] sergiusens: we need to support pinning, to keep the sources in a known good version. [15:59] elopio: it's possible that I just don't have *all* the output. Getting output from the script this way is not really the best. It's more intended for logging messages from provisioning rather than as a debugging tool for your scripts [16:00] plars: hum, that's possible. There is a lot of output. [16:00] elopio, you can pin with source-tag, source-branch to some extent [16:00] mvo, you seem to be using 16.04 syntax [16:00] sergiusens: fyi, snappy-debug 0.7 fixes the issue and is in the store [16:00] elopio: have you tried running this from a bbb locally to make sure it works? [16:00] plars: yes. [16:01] I have made many tiny changes trying to collect some output, so I will try again. But it's great news to see that the tests are starting. [16:02] jdstrand, so for fchown it is not going to be allowed and I need to fix it with a security.override? [16:02] s/./-/ [16:02] elopio, it seems that we don't have access to the store (or the internet for that matter) from the instances http://10.55.32.74:8080/job/github-snappy-integration-tests-cloud/10/consoleFull [16:02] plars: the troubling situation is that this should be bullet proof now. It doesn't have -e, so it won't stop the execution on failure. And I do > "$pwd"/output.txt 2>&1 which should collect any possible error. [16:02] that's where I'm lost. I don't understand why I get no output at all. [16:03] elopio, Get https://system-image.ubuntu.com//ubuntu-core/rolling/edge/generic_amd64/index.json: dial tcp 91.189.88.142:443: i/o timeout [16:03] tyhicks: hey, so, chown seems to be coming up all the time now [16:03] fgimenez: yes, I bet the scalingstack firewall is too strick. We need it open for a lot of things. Would they get mad if we just ask to remove it? :) [16:04] sergiusens: is that bad :) ? [16:04] jdstrand: chown to what? [16:04] sergiusens: aha, ok. I see that it is bad, I will use a different syntax [16:04] elopio: let me take a look [16:04] mvo, no, it just won't work [16:04] sergiusens, is that sqlite ? [16:04] tyhicks: like, 4 times in a week. our stance has been that we won't allow it until we have per-app uids [16:04] ogra_, yes [16:04] sergiusens, if so, i have a patch ;) [16:04] jdstrand: right [16:04] tyhicks: sqlite is doing a superfluous chown [16:04] elopio: what do you get on the spi side? do you get your results json uploaded there? [16:04] tyhicks: chown root:root /path/to/db [16:04] jdstrand, it isnt actually superfluous [16:04] tyhicks: and it is getting killed [16:05] plars: no. empty result_payload [16:05] ogra_: it is, cause the db is already root:root [16:05] jdstrand, it does that to make sure the db file matches the master file ... with the UID the master file was created with [16:05] elopio, :) with 91.189.88.142:443 will do for now IMO, we are just accessing the store? [16:05] so it is valuable in non-snappy [16:05] and the master file will be root:root [16:05] fgimenez: aren't we accessing also docker servers? [16:05] I understand the non-snappy case and why they are doing it [16:05] but since it tries to chown to a user thats not you usually it only does that when run as root [16:06] I'm talking about the snappy case, it is superflous because it does the chown unconditionally whether it needs it or not [16:06] right [16:06] anyway [16:06] elopio, https://github.com/ubuntu-core/snapcraft/pull/130 [16:06] tyhicks: so all of a sudden everyone is hot on sqlite [16:06] elopio, no, that's from canonistack, where the infra lives. the instances just need the store [16:07] tyhicks: and I'm getting pings left and right on this [16:07] fgimenez: great. Then yes, please make an RT to request opening the firewall to the store. [16:07] tyhicks: I've suggested we fix sqlite in the archive so that it does the chown conditionally [16:08] sergiusens, http://paste.ubuntu.com/13601278/ [16:08] tyhicks: but that hasn't happened yet and that doesn't fix vivid and doesn't fix something else that might do the same [16:08] sergiusens, for the upstream sqlite tarball ... [16:08] elopio: ok, can you try now? I updated the git tree to use the unconfined template [16:08] sergiusens, or just pull the binaries out of my upnp-server packages if you are lazy ;) [16:09] ogra_, I am lazier, a lot lazier [16:09] tyhicks: I've been thinking that when we have syscall arg filtering, we will allow 'chown 0' (or whatever the syntax) in addition to 'chown 12345' for per-app, if/when we do that [16:09] mvo: trying. [16:09] (after all you only need the sqlite3 executable and the lib) [16:09] sergiusens, bah [16:09] hacking security ! so evil :P [16:09] tyhicks: per-app aside, when we have syscall arg filtering, the 'chown 0' one would fix sqlite [16:10] tyhicks: but that won't happen until after the new year [16:10] elopio: ok, there seem to be some garbage characters in the output. I wonder if that's why things are getting a bit messed up. It's definitely failing though [16:10] elopio: https://pastebin.canonical.com/145191/ [16:10] tyhicks: on rolling, there is the saying things can break at any time [16:11] tyhicks: I've been reluctant to allow chown in the seccomp policy since that opens the floodgates to all uids, only to reign it in again later and potentially break stuff [16:11] tyhicks: but maybe that is actually ok for 16.04 [16:12] tyhicks: and 15.04 is simply what it is [16:12] mvo: still permission denied on mountinfo. [16:12] now I didn't have to hw-assign /dev/null [16:13] tyhicks: more clearly-- what do you think of me adding chown family to 16.04 policy now with a TODO to adjust when seccomp arg filtering exists? [16:13] jdstrand: if an app can chown in its data directory, what does that mean for this policy: [16:13] # Writable home area for this version. [16:13] owner @{HOMEDIRS}/*/apps/@{APP_PKGNAME}/@{APP_VERSION}/ w, [16:13] owner @{HOMEDIRS}/*/apps/@{APP_PKGNAME}/@{APP_VERSION}/** wl, [16:13] elopio: here's the json it spits out for spi to get, which is not valid and would probably fail for several reasons: http://paste.ubuntu.com/13601335/ [16:13] jdstrand: do we drop owner? [16:13] elopio: hm, thats confusing, let me dive deeper [16:13] plars: right. Let me pastebinit. [16:14] jdstrand: that's from the default template [16:14] yes, I recognize the rule [16:14] * tyhicks is trying to think through what it means to allow chown [16:15] fyi, this is exactly the sort of thing I have been saying could cause unintended interactions [16:15] and hence my reluctance [16:15] * tyhicks agrees [16:15] tyhicks: that rule is actually terribly problematic, but that is another story [16:16] mvo: this is not urgent. I'm just trying to make sense of the examples. [16:16] tyhicks: the launcher is really not smart about that directory and will create ~/apps/... as the root user [16:16] elopio: hm, my latest git seems to work in my snappy now, what git revno is the one you have? [16:16] and then running stuff as non-root is broken [16:16] elopio: just did "snapcraft assemble --force" and copied it to a snappy system [16:16] but that is another issue (there is a bug for that) [16:16] mvo: 6901dc912162b05fa381ead0e6d344152a68bbe9 [16:16] I think we *must* keep the owner checks there [16:17] I did snapcraft clean and snapcraft. Copied it to 15.04 stable #10. [16:17] jdstrand: I guess sqlite is not chowning files in that directory? [16:17] tyhicks: it is doing it in /var/lib/apps [16:17] ah [16:18] elopio: thanks, let me try that too. the version looks correct [16:18] well, I'm assuming. everyone is talking about services [16:18] and the services should be using SNAP_APP_DATA_PATH [16:18] not SNAP_APP_USER_DATA_PATH [16:19] jdstrand, correct [16:20] mvo, elopio we use git upstream, but our example tree has its own snapcraft.yaml [16:20] tyhicks: adding the chown now would mean that an app could perform a DoS on the SNAP_APP_USER_DATA_PATH [16:20] tyhicks: but I think that will be true when we add 'chown 0' [16:20] hrm [16:20] * sergiusens will bbl [16:20] jdstrand: but that DoS is only for itself [16:21] jdstrand: it wouldn't affect other snaps [16:21] for itself but for another user [16:21] oh, right [16:21] that's a problem [16:21] doesnt the launch wrapper prevent you from that ? [16:22] that will be true of 'chown 0' and 'chown 12345' too though [16:22] when we have syscall arg filtering [16:22] (how would you mangle SNAP_APP_USER_DATA_PATH to be for another user ? ) [16:22] (given the launcher will set it after you touched it) [16:23] ogra_: a malicious app doesn't have to use SNAP_APP_USER_DATA_PATH, it would be able to chown any path it chooses [16:23] ah [16:23] ogra_: you wouldn't-- but you can read /etc/passwd (necessarily) to get the paths of other users [16:23] well, /var/lib/extrausers/passwd but yeah, i get what you mean :) [16:24] (/etc7passwd is rather useless) [16:24] right. both are readable in the default policy (they must be) [16:24] yeah [16:25] jdstrand: I think that I need some more time to think about this [16:26] tyhicks: I think to properly support @{HOME} with chown we need fine-grained mediation of chown in apparmor and something more than 'owner', or a kernel side var to expand @{HOME} in some manner [16:26] tyhicks: I agree. this is the sort of thing I have been saying is problematic with chown [16:28] ogra_, sergiusens: I'm fairly certain we aren't going to just add chown to the policy any time soon. we may be able to fix it this cycle. I suggest someone update sqlite in the archive to make the check conditional [16:28] tyhicks: fyi ^ [16:28] well, i'm just using upstreams tarball now ... [16:28] would be nice if snapcraft had a concept of patching though ... so i dont need to build in two steps [16:28] most people will surely opt to snapcraft the deb though, no? [16:29] yeah [16:29] well my hackish patch from above is definitely not suited for the package [16:29] jdstrand: tyhicks: so we need to change things so that SNAP_APP_USER_DATA_PATH is under the home of the effective user, right? [16:29] (it blindly just rips out all chown calls) [16:29] ogra_: using ld_preload? [16:30] Chipaca, for what ? [16:30] ogra_: for ripping out the chown calls [16:30] well, replacing them [16:30] not for sqlite [16:30] well, sqlite consiste of two binary files ... i just drop them in the right place with the copy plugin [16:31] Chipaca: he patched out the calls to chown(2) [16:31] usually i have some debs involved so i get the wrapper setup that gives me LD_PRELOAD anyway [16:31] but having to patch the code means i need to build it separately from the snapcraft run [16:31] Chipaca: the problem with the launcher is that $HOME of the real user is being used for the euid of 0 under sudo [16:32] jdstrand: yes [16:32] Chipaca: which is why we get root owned dirs in $HOME [16:32] yes [16:32] this isn't about fixing all that, though that is an incredibly annoying bug [16:32] http.chipaca comes up against this a bit [16:32] do you know the bug number offhand? [16:32] let me find the bug [16:32] heh [16:32] I'll find it [16:33] https://bugs.launchpad.net/snappy/+bug/1466234 [16:33] Launchpad bug 1466234 in Snappy "Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root" [Critical,Triaged] [16:33] Chipaca: ^ [16:34] tedg suggests in comment #2 that we shouldn't set SNAP_APP_USER_DATA_PATH for root [16:35] yes, but agreed with setting it because there are valid reasons for using it [16:35] Root isn't a user :-) [16:35] Chipaca: that is one idea. someone told me to not include /root in the policy, which is why we don't now. another option is setting SNAP_APP_USER_DATA_PATH to SNAP_APP_DATA_PATH [16:36] wrt stgraber, I suspect this was running as root, not with sudo [16:36] when running as root [16:37] Chipaca: I think the lxc command is a binary in the lxd package [16:37] * jdstrand checks [16:37] Chipaca: yes, it is. so he used 'sudo lxc' at the time [16:39] plus, only the launcher does the mkdir, not the services (unless they wrote the service to do it) [16:39] well, actually, scratch that [16:40] I forgot for a moment the luancher is used by the systemd service [16:42] so, from a traditional security perspective, it is probably wrong to have a process running under sudo to read files from the real user's home directory, so the current behavior of setting SNAP_APP_USER_DATA_PATH to the real user's home is wrong [16:42] tyhicks: what do you think? ^ (different topic from chown-- looking at 1466234 now) [16:44] just a minute - I'm in a meeting [16:46] oh, I'm supposed to be in that meeting [16:46] actually, I'm optional there [16:47] jdstrand: it just ended [16:47] jdstrand: yes, I dislike the idea of root mucking with files in the user's home dir [16:47] me too [16:47] Chipaca: ^ [16:48] jdstrand: with chmod being allowed now, there's nothing stopping services from dropping setuid root binaries in a user's home dir :/ [16:48] Chipaca: I think the choice is to either not set SNAP_APP_USER_DATA_PATH when running as root or set it to SNAP_APP_DATA_PATH [16:48] jdstrand: not to /root/apps/yadda/yadda? [16:49] well, that is another choice, yes. I was explictly told *not* to allow that, and I asked in the bug for why, and got no response [16:50] asac: hey, do you recall why we didn't want to allow the launcher to create /root/apps/pkgname/version ? [16:50] mvo: do you? ^ [16:51] is /root writable ? [16:51] it is these days [16:51] ah, i see [16:51] it is in /etc/system-image/writable-paths [16:52] it may not have always been [16:52] yeah, i think it hasnt in the past [16:52] I don't know how this would fit into all snaps either [17:06] plars: can you check once again, please? [17:08] elopio: http://paste.ubuntu.com/13602227/ [17:09] plars: nice! [17:09] now I don't understand why the payload is still empty, but things are improving. [17:11] plars: can you please install the subunit package? [17:14] elopio: done [17:14] thanks [17:21] elopio, can you check my last comment on https://github.com/ubuntu-core/snapcraft/pull/130 [17:24] sergiusens: how could it be running on 80 if you are calling it with 8080} [17:24] ? [17:25] I don't get a defunct service. [17:30] elopio, just run `sudo netstat -putan` (as a spanish speaker it is hard to forget those netstat switches :-P) [17:30] elopio, I might have messed up the flags, that is why I ask ;-) [17:31] sergiusens: it's not in 80, nor in 8080. But snappy service status says it's active and running. [17:32] elopio, snappy service is wrong; check `ps -ef|grep gopaste` [17:32] sergiusens, pretty sure they're order independent :P [17:32] sergiusens: yes, defunct. [17:32] sergiusens: I agree that it's better than before, fwiw. [17:32] Chipaca: ok, typos aside, I laid everything out in https://bugs.launchpad.net/snappy/+bug/1466234/comments/6 [17:32] Launchpad bug 1466234 in Snappy "Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root" [Critical,Triaged] [17:33] elopio, let's merge this then and I'll think of how to get sqlite working [17:33]