[02:48] PR snapd#6217 opened: tests: reset snapd state on tests restore [04:18] Bug #1753760 changed: Adding public RSA Key doesn't make login on device possible === chihchun_afk is now known as chihchun === zyga|afk is now known as zyga [06:46] o/ [07:34] People : hi ! [07:34] hello [07:48] brb, need to take the dog out === pstolowski|afk is now known as pstolowski [07:57] mornings [07:58] back to yesterday's test panic issue, the debug log from zyga shed some light on it [07:59] pstolowski: good morning and good luck wit hthat [08:00] Hey Paweł, Michael [08:00] mvo: I’m off the 2.36 bug [08:00] No progress made [08:00] Need to finish my stuff now [08:04] zyga: ok [08:06] zyga: may i ask you to try one more patch> [08:06] ? [08:18] Sure [08:19] zyga: https://pastebin.ubuntu.com/p/Kgs7tXTfRH/ [08:26] pedronis: re 6195 - shall we (after this got a second review) merge and do 2.36.2 and then look for a better place for this than link_snap.go? or would you rather like to look for this place now before it goes to master? [08:31] PR snapd#6218 opened: snapstate: update fontconfig caches on install (2.36) [08:59] zyga: actually that patch won't help; i'll have another one soon [09:00] i wish i understand what the delta is between our setups and why it doesn't fail for me on travis, pretty weird [09:17] pstolowski: re, sorry, had a delay and network woes [09:18] pstolowski: yeah [09:18] pstolowski: if you want I can give you ssh access [09:18] not sure if that would help [09:18] to my box [09:18] where this happens [09:18] I can work on another [09:23] zyga: yeah, that could help, thanks. also question, did we change anything related to finding if apparmor should be enabled or not recenlty? it looks like setup-profiles in this test now wants to read vanilla snap-confine profile of core; this happens if we find that release.AppApparmorLevel != NoApparmor. we're not mocking vanilla profile in the mock core snap obviously [09:24] mvo: you might know as well^ [09:24] pstolowski: not sure when is recently [09:24] when apparmor is not entirely disabled we operate [09:24] including making a special profile for snap-confine itself [09:24] if you think mocking is missing by all means, add some [09:25] yep. it's just curious it's not happening consistently [09:26] moin moin [09:26] hey Chipaca [09:26] have you seen https://forum.snapcraft.io/t/disable-enable-not-longer-working-when-snap-have-gpio-pins-as-connect/6473 ? [09:26] oh noes [09:26] well [09:26] this is a bug we fixed [09:27] zyga: "withthe edge channel" of core presumably? [09:27] yes [09:27] morning Chipaca [09:28] Chipaca: your questions got me curious [09:28] so I did some more experiments on https://github.com/snapcore/snapd/pull/6147 [09:28] PR #6147: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces [09:29] and I believe we understand why additional permissions are required [09:29] my only question now [09:29] should I split the permissions so that snap-update-ns is called with the existing profile transition [09:29] and the only permission we have remains "r" [09:29] adding a new block for snap-discard-ns which runs with the same profile [09:29] or is the patch as-is good enough? [09:30] zyga: WWJ(S)D? [09:30] split it [09:30] :-) [09:30] for maximum confinement [09:30] I'll do that [09:30] btw, love the acronym :D [09:39] Chipaca: https://github.com/snapcore/snapd/pull/6147 is ready now [09:39] PR #6147: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces [09:40] eh [09:40] https://gitlab.gnome.org/GNOME/gnome-control-center/issues/230#note_373259 [09:50] PR snapd#6219 opened: overlord/tests: [WIP] fix panic in managers test [10:00] I need a 2nd review for https://github.com/snapcore/snapd/pull/6147 [10:00] PR #6147: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces [10:01] Chipaca: thank you! [10:21] I also need a 2nd review on https://github.com/snapcore/snapd/pull/6159 [10:21] PR #6159: cmd/snap-confine: handle mounted shared /run/snapd/ns [10:31] zyga: +1 with one question [10:33] PR snapd#6159 closed: cmd/snap-confine: handle mounted shared /run/snapd/ns [10:33] answered [10:33] thanks! :) [10:33] mvo: what's the 2.36 weather like? [10:37] zyga: medium, still see failures but can't reproduce them [10:38] mvo: magic [10:38] mvo: pstolowski is working on a fix for the panic I can reproduce trivially [10:38] I'll just run tests for his incremental patches [10:38] zyga:you can try https://github.com/snapcore/snapd/pull/6219 [10:38] PR #6219: overlord/tests: [WIP] fix panic in managers test [10:38] sure thing [10:39] zyga: btw, it's green, does it mean anything? [10:39] test in progress [10:39] cause i can't repro here, pretty annoying [10:40] pstolowski: I can try to run this after my current run, I had some luck reproducing the panic [10:45] mvo: thanks. i tried running it with spread -debug -repeat 10 google:ubuntu-16.04-64:tests/unit/go [10:51] mvo: I hopefully answered in the PR [11:02] pedronis: ta [11:03] np [11:03] * pedronis goes back to swap daying [11:04] pstolowski: I am running it now again, lets see [11:13] Brb, coffee or something warm [11:26] pstolowski: https://paste.ubuntu.com/p/9rj8ydFg5p/ <- I cherry picked 1c5b166643a5623b0a534fd1a8acb7d03d50d856 from 6219 earlier [11:29] mvo: aha, interesting, let me mock core rev 1 as well [11:30] pstolowski: shall I run it again? [11:30] pstolowski: I mean, after you upated the pr? [11:35] mvo: i've just pushed a change [11:35] mvo: thanks! [11:35] pedronis, I am working again with the #5714 [11:36] PR #5714: tests: new test for cifs-mount interface [11:50] 6195 needs a second review [11:55] mvo: I reproduced 2.36 bug again [11:55] pstolowski: no panic yet [11:56] zyga: are you running with the update i pushed a few minutes ago ^ ? [11:56] pstolowski: no, the one from earlier today [11:56] mock vanilla profile for snap-confine [11:57] mvo: same thing, apparmor parser killed by signal [11:57] zyga: ok; yeah, i think one more revision of core in the tests needs it too, i added it [11:57] ok [11:59] zyga: anything interessting why its killed? [11:59] mvo: I cannot find any information about why [11:59] zyga: or what signal? sigter [11:59] hits appreciated [11:59] zyga: meh :( [12:00] I suspect sigterm because it says "terminated" [12:01] ah [12:01] something interesting [12:01] mvo: look at this [12:01] lots of terminated errors https://www.irccloud.com/pastebin/FVHUi8t8/ [12:01] I thought it is just one time [12:02] mvo: it's not just once [12:02] it seems to happen all the time [12:02] snap changes https://www.irccloud.com/pastebin/2UoYFGwX/ [12:04] *hmm* [12:04] mvo: note that this branch doesn't have the tweak I used before [12:04] so the error was not fatal [12:04] I was testing pawel's patches [12:04] I will record the seed and continue unless anyone has some better idea [12:07] ok, seed is -seed=1543315161 [12:07] I will pull more of pawel's patches [12:08] as well as my stashed error handling [12:08] and let's see [12:08] zyga: thank you [12:08] zyga: I run it also with your diff to make the error fatal [12:09] zyga: but so far no luck in reproducing [12:09] restarted [12:09] back to working on feature [12:13] what's holding back snapd on debian? [12:14] Chipaca: AFAIK there's a test failure that happens there [12:14] but no investigated [12:14] I mean packaging-wise [12:14] it's on 2.30 [12:14] and no reexec [12:15] I believe you are wrong, there is reexec [12:15] hmm [12:15] as for the package, nobody released updates [12:17] I wonder if deepin mangles os-release or sth, then [12:17] * Chipaca installs deepin [12:17] note that we have a blacklist, not a whitelist [12:17] no we don't [12:17] I mean [12:17] if !release.DistroLike("debian", "ubuntu") { [12:18] that's a whitelist, even if it has a "not" in front of it [12:19] oh [12:19] indeed [12:19] that's new to me [12:19] zyga: reading a bit of above, "terminated" is the %s of signal 15 [12:19] aha [12:19] sigkill [12:19] that's odd [12:19] wonder why we do that [12:19] zyga: /usr/share/go-1.6/src/syscall/zerrors_linux_amd64.go [12:19] (not really us probably) [12:19] ze errorz zey keep koming! [12:20] I think it's just shorthand for "zee autogeneraed files" [12:20] zyga: 15 is TERM, so what else would you call it? [12:21] ah, sorry [12:21] 9 is kill [12:21] :-) [12:21] I did make tea, not coffee [12:21] so terminated [12:21] and 9 would say "killed" [12:21] maybe test setup? [12:22] there is one silly way to fix it :) [12:22] we could wrap aa-parser with an apparmor profile [12:22] that rejects SIGTERM :D [12:22] (I'm half serious) [12:22] might help us to pinpoint the sender [12:22] because we would get a denial [12:25] * pstolowski lunch [12:33] is maciej around today? [12:33] ah, he called in sick [12:33] ok [12:43] https://forum.snapcraft.io/t/cannot-run-any-program-trace-breakpoint-triggered-errors/8707?u=chipaca if anybody has clues about apparently x11 being broken on deepin [12:44] * zyga thinks [12:45] I know [12:45] zyga: i'm going to get lunch, but i'll read when i return [12:45] ls /tmp/.X11-unix [12:45] on ubuntu we use abstract socket to talk to x [12:45] on some systems we don't [12:46] without special support we won't have x socket [12:51] If snap A connects to snap B via a content interface, can snap A execute binaries within snap B? [12:51] Wimpress: yes, but must use the internal interface, not via "snap run ..." or /snap/bin/..." [12:51] and said binaries run with confinement of snap A [12:52] snap A is confined. [12:52] snap B might be classic ;-) [12:52] by internal interface I mean by knowing how to execute the binary directly from where the content sharing is establieshed [12:52] Wimpress: content sharing shares bits and bytes [12:52] not changing anything else [12:52] does't grant more permissions to run [12:52] or not run [12:53] OK, so by virtue of having the snaps connected, snap A can not execute binaries from snap B. Correct? [12:53] no, that's not correct [12:53] if I have a snap that contains a shell script [12:53] and I expose that via a content interface [12:53] and that interface is connected to some other sna [12:54] that other snap can invoke that shell script [12:54] Excellent. [12:54] that shell script may not be an exposed application [12:54] and in fact if it is an exposed application [12:54] I cannot use that exposed application from any snap [12:54] note that this doesn't imply any more permissions [12:55] if you content-connect to LXD, for example, you don't get to run LXD with all the powers attached [12:55] So snap A would have to invoke the binary in snap B via a full path? [12:55] it's just a way to share bytes [12:55] Wimpress: with path, environment and any other quirks required [12:55] it's as easy or hard as the associated binary implementation details are [12:57] Would binaries snap A want to execute from snap B be referenced via /snap/snapA/current/bin/foo or via /snap/snapB/current/bin/foo? Or will $SNAP be fine? [12:57] neither, you need to use the real path where they are shared [12:57] so if you share them to, say [12:57] $SNAP/plugins/ [12:57] and find them there [12:58] you need to know to call $SNAP/plugins/foo/bin/plugin.bin [12:58] $SNAP or any other variables are not aware of that [12:58] they will not know anything about any connected content interfaces (perhaps many) [12:58] they will always point to the snap for which the main process was started [12:58] (snap A in this case) [12:58] OK. Sounds promising. [12:59] So, if snap A (confined) is connecting to snap B (classic), snap A can execute binaries exposed from snap B but within the confinement defined by snap A. Correct? [12:59] yes [13:00] Cool. [13:00] it's really just the same [13:00] as if they were copied into snap A [13:00] it's just a way to share bytes [13:00] Just wanted to be clear. [13:00] sure [13:00] zyga: am back. Indeed /tmp/.X11-unix/X0 is where it's at [13:01] yay [13:01] zyga: so what do I do? [13:01] we can easily fix that too [13:02] hold on [13:03] looking for something [13:05] Chipaca: in cmd_run.go we handle XAUTHORITY [13:05] we could handle X11 socket [13:06] zyga: handle it how? [13:06] ha, that's tricky [13:07] we can see the socket [13:07] but not access it [13:07] perhaps we should preserve /tmp/.X11* in snap-conifne [13:07] which is not terribly hard but not super easy either [13:07] Chipaca: can you please file a bug [13:07] or find one [13:07] I bet people reported it [13:07] there are also mentions of this on the forum [13:07] zyga, hey [13:08] zyga: I mean, this is from the forum :-) [13:08] Chipaca: let's cross reference them then [13:08] cachio: hello [13:08] zyga, I could make the cifs test work but ... [13:08] zyga, just adding this to the interface "/run/mount/utab rw," [13:08] zyga: I wonder if there's a way to tell X to use abstract sockets [13:08] I think we discussed that [13:09] cachio: we should not do that [13:09] Chipaca: some systems don't have one [13:09] zyga, based on the comment we shouldn't [13:09] cachio: we cannot add that permission because that would allow snaps to confuse the host's libmount about what certain attributes are [13:11] zyga: it seems to also have an abstract socket, @/tmp/.X11-unix/X0 [13:11] Chipaca: is there anything in the environment [13:11] any X... variable set? [13:11] maybe we can do a low cost fix [13:12] "unset XSTH" [13:13] nothing that I can see [13:14] dunno then [13:18] zyga: and if I install with devmode it workss [13:18] oh [13:18] that's odd [13:18] zyga: so it's not the /tmp/.X11 socket [13:18] what's the denial? [13:18] zyga: it's access to the socket itself [13:18] mvo: any news on the 2nd run of https://github.com/snapcore/snapd/pull/6219 ? [13:18] 1 sec because I accidentally killed the vm :-) [13:18] PR #6219: overlord/tests: [WIP] fix panic in managers test [13:19] pstolowski: I ran it again, 0 failures [13:19] restarted (thanks for reminidng me) [13:19] nice, thanks [13:19] fwtw travis pass was green again [13:22] [ 157.486384] audit: type=1400 audit(1543324906.843:348): apparmor="DENIED" operation="create" profile="snap.xbill-xaw.xbill-xaw" pid=3187 comm="xbill" family="unix" sock_type="stream" protocol=0 requested_mask="create" denied_mask="create" addr=none [13:22] had to purge the charon thing to get to see that [13:22] hold on [13:22] * Chipaca goes to check on the soup [13:22] weird [13:23] soup for lunch isn't that weird [13:23] i've got a bad cold [13:23] ¯\_(ツ)_/¯ [13:23] niemeyer, zyga: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ba8845b83b [13:23] this might make you guys happy :) [13:23] indeed [13:23] Son_Goku: mborzecki is sick, he's off today [13:23] but I'll make sure he knows [13:23] ah, that's too bad [13:23] hope he feels better soon :) [13:24] Chipaca: which interfaces do you have connected [13:24] Chipaca: x11 plug grants socket AF_NETLINK, not unix [13:24] also allows some x abstractions, reading on those now [13:25] Chipaca: but nothing grants access to that socket [13:25] Chipaca: could it be the case that apparmor simply doesn't handle abstract sockets [13:25] and we never noticed? [13:26] sounds like a jdstrand question :-) [13:26] or, maybe a jjohansen ? if i remember people right [13:26] * Chipaca often doesn't [13:30] mmm, tasty tasty schadenfreude http://forum.asrock.com/forum_posts.asp?TID=10174 [13:32] Chipaca: both would know [13:32] ok, i'm off to have actual lunch now [13:32] ttfn [13:32] good idea [13:33] I'll wait till after standup [13:33] I'd love to land https://github.com/snapcore/snapd/pull/6147 [13:33] PR #6147: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces [13:33] mvo: can you do a quick review, in mborzecki's absence [14:22] zyga: https://pastebin.ubuntu.com/p/B5d5n36p2h/ might this be relevant to the x11 thing? [14:22] maybe [14:27] mvo: the bug is https://bugs.launchpad.net/snapd/+bug/1805182 [14:27] Bug #1805182: /tmp is sometime cleaned up after snaps are launched [14:39] socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) vs socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) [14:53] PR snapd#6220 opened: cmd: drop cruft from snap-discard-ns build rules [14:53] mvo: can you do a quick review of https://github.com/snapcore/snapd/pull/6147 please [14:53] PR #6147: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces [14:53] it's green and if it lands I can continue [14:53] and has one and a half review [14:54] zyga: I try, have a lot of meeting now :/ [14:54] ok [14:54] pstolowski: perhaps you ^ [14:54] 6147? [14:54] zyga: ^ [14:55] yes [14:55] ok [14:58] meanwhile, 2.36 branch for those errors [15:02] mvo: I just realized something [15:02] the terminated error is not new [15:02] we probably had it since forever [15:02] but we would not notice it until the special situation in 2.36 branch [15:02] this doesn't change why it is broken [15:03] but may help us form new perspective [15:03] because we had ignored those errors all the time [15:03] we would just happily carry on [15:03] PR snapcraft#2417 opened: Revert "lifecycle: make snapcraft init template use > not | (#2393)" [15:09] PR snapd#6221 opened: interfaces: return security setup errors [15:10] mvo: this one is for you https://github.com/snapcore/snapd/pull/6221 [15:10] PR #6221: interfaces: return security setup errors [15:29] PR snapd#6222 opened: cmd/snap: handle DNS error gracefully [15:33] pstolowski: nice [15:33] pstolowski: 0 errors [15:34] zyga: very nice, thanks, i'm cleaning that PR atm, will push an update [15:34] pstolowski: I woudn't mind a follow up [15:34] this looks sane as-is [15:38] well it outputs debug [15:38] pushed [15:38] i'll cherry pick into master [15:38] * cachio lunch [15:40]