=== chihchun_afk is now known as chihchun [05:32] o/ === pstolowski|afk is now known as pstolowski [07:03] mornings [07:30] pedronis: hey, thanks for the review! i've updated #5952 [07:30] PR #5952: tests/ifacestate: moved asserts-related mocking into helper [08:00] niemeyer: woah, thanks for the reviews on hotplug stuff! [08:02] zyga: HAH! flatpak got a haters site before snap! i won! :) [08:04] alexlarsson: (insert meddling kids comment) [08:04] alexlarsson: I firmly believe we are both building the better future for app developers [08:04] No no no [08:04] We're evil masterminds! [08:04] alexlarsson: I woundn't mind that website much if the person was not anonymous [08:05] Man, you're not following the PLAN! [08:05] ah, where is my script :) [08:05] "what are we going to do tonight brain" [08:07] I think my problem with it is that *all* the things in there all apply to .deb/.rpm too (other than potentially flathub having less resources for CVE fixing than some distros) [08:07] So, what do they recommend? [08:07] still one thing I would agree on, the sandboxing tech available in linux is still spotty, there are compromises for early usability [08:08] I think those are fine as long as we are 100% honest about it [08:08] Well, *allowing* a sandbox is better than not allowing it. And if we enforced it no apps would work and people would make hater sites for that. [08:09] can't win the internet [08:16] alexlarsson: although I think flatpack could use some of the --classic prompts from snapd [08:16] alexlarsson: to install an app that has wide-open access to one's system requires to be explicit about it [08:16] We do that in the CLI [08:16] but gnome-software doesn't atm [08:16] mmm, I see [08:17] org.gnome.gedit/x86_64/stable flathub a03b66681bce [08:17] permissions: ipc, wayland, x11 [08:17] file access: host, xdg-run/dconf, ~/.config/dconf:ro [08:17] dbus access: ca.desrt.dconf, org.gtk.vfs.* [08:17] Is this ok [y/n]: [08:18] and we track it so you get deltas displayed on update [08:18] alexlarsson: those are super technical and end with a yes-no question [08:18] those are really asking "do you want this app or not" [08:18] I think it could still use a lot of polish and change to the final prompt [08:18] Yeah, but its *hard* though [08:18] like [08:19] alexlarsson: g-s doesn't? i thought we'd fixed that? [08:19] many of those are instant sandbox escape [08:19] x11 => escape [08:19] I think we should phrase it around "do you want to give this application access to your system" [08:19] write to home => escape [08:19] write to dconf => escape [08:19] not around technojargon that even system developers may not fully grasp (the consequences of granting) [08:20] dconf? because auto-start unconfined this way? [08:20] (i'm sure there is a list of things that is spawned stored somewhere in dconf) [08:20] right [08:20] * zyga wonders what we do about dconf [08:20] We want to do a portal for it [08:20] but it hasn't happened yet [08:20] TingPing is looking at it soon [08:21] org.freedesktop.ibus.engine.anthy.common add-word-command ['/usr/bin/kasumi', 'kasumi', '-a'] [08:21] dconf exploit [08:23] org.gnome.desktop.default-applications.office.calendar exec 'evolution -c calendar' [08:23] another one [08:24] Basically, i think its to risky to try to describe it in non technical words and give people the feeling that they only gave "secure" access [08:25] The only thing i think is possible is to mark what we consider a good sandbox with some "sandbox" tag [08:25] and then the rest is, "do you trust these guys, oh and here is some techincal gobbeligok" [08:25] hmm, I think I recall we did apparmor for dconf somehow [08:25] but perhaps that didn't materialise in the end [08:26] one that would see the get/set arguments (normal apparmor dbus doesn't) [08:26] I agree on the trust aspect [08:26] it's either strong tech or it is trust [08:27] pstolowski: np [08:27] Mornings [08:27] hey hey [08:30] there is no runuser in 14.04 /o\ [08:30] * Chipaca thinks SRU thoughts [08:31] Chipaca: careful, that kinda thinking leads to dangerous places [08:31] IKR [08:32] next thing you'll be doing a version bump [08:32] Chipaca: please update centos kernel too ;) [08:32] yes. and replace yum with apt-get [08:32] zyga: I'll file an SRU for that [08:32] zyga: OH WAIT [08:33] that'ld be an epic project - a seamless upgrade from centos to debian or ubuntu :-p [08:33] i.e. one that doesn't require a separate boot disk [08:33] reminds me of a conversation we had way back in the Córdoba LUG [08:33] diddledan: curl flash.io/whatever | sudo dd of=/dev/sda [08:33] ;-) [08:34] right about when macro virii became "popular", and we were building linux distros of the size of these things [08:34] anyhoo [08:35] speaking of virii /me downloads backorifice and sub7 [08:35] I'm hip now [08:35] I guess what I need to do is make maybeRunuserCommand check the release and use sudo if runuser isn't available [08:35] … or maybe run sudo always? [08:35] grmbl grmbl grmbl [08:37] I love maybe functions - maybeSaveDataThatCannotBeLost [08:37] and then you get really functions - reallySaveTheData [08:38] niemeyer: is this for real? https://twitter.com/Zondi_Elihle/status/1049557185502609409 [08:40] diddledan: names are hard; suggestions always welcome [08:40] i'd have a tattoo, if i did tattoos [08:44] morning [08:45] hey mborzecki o/ [08:46] hey guys [08:49] PR snapd#5953 closed: apparmor: create SnapAppArmorDir in setupSnapConfineReexec [08:49] thank you again mvo [08:50] zyga: for what? [08:50] for that PR [08:50] zyga: I mean, appreciated :) [08:50] zyga: oh, yeah [08:50] zyga: it was slightly tricky to find but simple in the end [08:53] zyga: That's so over the top that it's hard to believe indeed.. let me check [08:53] mborzecki: do you have a moment for https://github.com/snapcore/snapd/pull/5952 ? [08:53] PR #5952: tests/ifacestate: moved asserts-related mocking into helper [08:53] zyga & niemeyer: re tweet → https://twitter.com/_majubs/status/1049794758162432002 [08:54] pstolowski: will do [08:54] ah [08:54] pstolowski: I just did that one [08:55] dot-tobias, zyga: There are many non-joke programs in Multi Show, and it's a channel from Globo which tends to be trustable.. [08:55] mvo: ah, thanks! [08:55] mborzecki: no need then, thanks! [08:56] niemeyer ,zyga: Maybe the security cam footage is real and they added a satirical “interview” – his answers are just so full with double-entendre and humor 😄 [08:57] dot-tobias, zyga: Yeah, it's a joke.. JS, "Satirical Journal" [09:00] zyga: hey [09:00] zyga: snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks [09:00] zyga: what did that mean? [09:00] it mean that snap-confine was not confined but should be [09:00] * Chipaca looks for his trout [09:00] it runs on a kernel with apparmor support that is enabled [09:00] but it has no profile of itself [09:00] zyga: this is inside a 14.04 spread thing [09:00] so it chooses to stop operating [09:00] it means that apparmor service did not load apparmor profile for snap-confine [09:01] is this in a live CD? [09:01] zyga: no, spread, using the qemu backend, on 14.04 [09:01] uname -a? [09:01] Linux autopkgtest 4.4.0-135-generic #161~14.04.1-Ubuntu SMP Tue Aug 28 11:17:49 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux [09:01] hmmm [09:01] magic [09:01] PR #161: Fix unclean tests [09:02] what is the status of apparmor.service? [09:02] mup: go home, you're drunk [09:02] Chipaca: I apologize, but I'm pretty strict about only responding to known commands. [09:02] zyga: Loaded: error (Reason: No such file or directory) [09:02] oh, there you go [09:02] zyga: um [09:02] zyga: wait, this is 14.04 [09:02] so? [09:02] zyga: no systemd [09:02] on 14.04 it should still be there [09:02] heh https://github.com/snapcore/snapd/pull/5951 travis status on github is still pending, but the travis job has successfuly finished 13h ago [09:02] aaaah [09:02] oh boy [09:02] i mean, systemd isn't in charge [09:02] * zyga thinks [09:02] PR #5951: spread-shellcheck: fix interleaved error messages, tweaks [09:02] so, ... [09:02] er [09:03] I forgot the upstart equivalent [09:03] mborzecki: hi! do you remember why I switched snapshots to use runuser instead of sudo? [09:03] Chipaca: can you please look at /sys/kernel/security/apparmor [09:03] and cat the policy file [09:03] Chipaca: nope, was sudo an option? [09:04] er [09:04] sorry [09:04] zyga: 1 sec [09:04] zyga: when do we print that message, in particular? [09:04] cat /sys/kernel/security/apparmor/profiles [09:04] not policy, profiles [09:04] Chipaca: when snap-confine starts up and noticed this [09:04] zyga: so [09:05] zyga: test-snapd-tools.echo hello [09:05] zyga: works [09:05] # su -l -c 'test-snapd-tools.echo hello' test [09:05] snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks [09:05] who has access to the forum? should this post be reinstated? it appears to have been flagged for some reason: https://forum.snapcraft.io/t/call-for-testing-savage-xr-battle-for-newerth-game/7754 [09:05] yes [09:05] Chipaca: because then it's not privilege ecalation [09:05] you were root [09:05] diddledan: too many links on a newcomer topic [09:05] diddledan: unhidden [09:05] aha [09:06] thanks [09:07] Chipaca: i think we moved from a helper to a goroutine with set*uid and then to runuser [09:07] zyga: I don't understand [09:07] mborzecki: i did try sudo first [09:08] mborzecki: in fact the variable in which I build the command is still called sudoArgs :) [09:08] Chipaca: when you are the user test [09:08] snap-confine gives you root [09:08] so it looks for confinement [09:08] Chipaca: hah :) so something must have been off about it then [09:08] when you were root, we just carry on [09:08] it is the logic we picked a while ago [09:08] mborzecki: exactly, and I remember you suggesting runuser instead, but I don't remember why [09:08] mborzecki: so, I'm going to just plug sudo back in there and see what breaks :-D [09:09] Chipaca: sec, let me check the logs [09:09] niemeyer: when you have a moment, could you please check if the name in the system-user assertion to force a password change (pr 5949) is ok. right now it is using "force-password-change: {true,false}" [09:09] PR #5949: osutil,asserts,daemon: support force password change in system-user assertion [09:09] zyga: so how do I work around this? [09:09] mvo: That sounds great already [09:09] Chipaca: well, figure out why the profile was not loaded [09:09] it should have [09:09] fist of all, please check if the profile is really absent [09:11] zyga: how do i check that? [09:11] Chipaca: https://paste.ubuntu.com/p/jNc3bTXKDR/ [09:11] i should trim the log file [09:11] Chipaca: please look at /sys/kernel/security/apparmor/profiles [09:12] zyga: snap.test-snapd-tools.echo (enforce) (and a bunch more) [09:12] do you see one for snap-confine itself? [09:12] this is about snap-confine profile, not app-specific profile [09:12] # grep snap-confine /sys/kernel/security/apparmor/profiles [09:12] snap-confine effectively kills itself by choice [09:12] zyga: yes, two results, which irc won't show as pasted because they start with / :) [09:13] haha [09:13] # grep snap-confine /sys/kernel/security/apparmor/profiles [09:13] /usr/lib/snapd/snap-confine (enforce) [09:13] yes, thank you IRC [09:13] /usr/lib/snapd/snap-confine//mount-namespace-capture-helper (enforce) [09:13] so that's the main profile [09:13] what we are missing is the reexec profile [09:13] this very much feels like the bug mvo just fixed [09:13] * Chipaca hugs mvo [09:13] is /var/lib/snapd/apparmor/snap-confine present? [09:13] zyga: no [09:14] an /var/lib/snapd/apparmor? [09:14] mkdir it please and restart snapd [09:14] wait [09:14] yes [09:14] yes, it's there, just empty [09:14] (i misread ls's output /o\) [09:14] ok, restart snapd and let's see [09:15] how do i restart snapd on 14.04 [09:15] man [09:15] ha [09:15] sudo service restart [09:15] AFAIR [09:15] but I may not remember much [09:15] it looks like snapd is running under systemd [09:16] oh right [09:16] well [09:16] there [09:16] restarted [09:17] any new profiles? [09:17] JamieBennett: are snaps part of the 14.04 ESM offer? [09:18] zyga: not that i can see [09:18] Chipaca: not that I know of [09:18] Chipaca: why? [09:18] JamieBennett: because I'd be happier if we could stop worrying about 14.04 soon :) [09:18] :) [09:19] zyga: so now what [09:19] Chipaca: I assume you have the core snap installed [09:20] zyga: i do [09:20] Chipaca: upon restart of snapd I would expect to see the reexec profile in the places you looked [09:20] ah [09:20] wait [09:20] I'm silly [09:20] the reexec profile is in /etc/apparmor.d [09:21] is there one in /etc/apparmor.d/snap.core.$NUMBER.usr.lib.snapd.snap-confine [09:21] zyga: no [09:21] any logs from snapd? [09:21] zyga: plenty [09:21] this is in spread, so all debug knobs are on [09:21] oh man [09:21] "all" <- most [09:22] can you please pastetem? [09:22] zyga: as of the last restart? [09:22] pedronis: splitting validation from snap is quite a puzzle [09:22] yeah, though no need to limit them just paste what you have [09:24] Chipaca: so sudo vs runuser was just about package dependencies? [09:24] mborzecki: looks like it, but i'll need to test [09:24] mborzecki: thank you for those logs :) [09:24] zyga: https://pastebin.ubuntu.com/p/Mc8jwBqMXk/ [09:24] zyga: slightly truncated horizontally; let me know if you need the full width [09:25] hmmm, nothing out of the ordinary [09:25] I don't know, why is the profile not there ? [09:25] hmm [09:25] actually [09:25] perhaps when we installed the core snap and the directory was missing [09:25] can you refresh core [09:25] to anything [09:25] sure 1 sec [09:25] that ought to trigger the right thing [09:26] refreshing to beta [09:26] (was on edge) [09:26] hmm, it hangs [09:26] hmm [09:26] oh no it worked [09:26] just no progress bar [09:26] wat [09:26] anyway, one wat at a time [09:26] no progrès bar? [09:26] zyga: # ls /etc/apparmor.d/ [09:26] abstractions cache disable force-complain local sbin.dhclient snap tunables usr.lib.snapd.snap-confine usr.sbin.cups-browsed usr.sbin.cupsd usr.sbin.rsyslogd usr.sbin.tcpdump [09:26] mvo: LGTM.. couple of trivial optional suggestions only [09:26] hola accents [09:27] Chipaca: hmmm no idea, something is bad [09:27] niemeyer: thank you! [09:27] zyga: :-/ [09:27] mvo: np and thanks! [09:29] zyga: should I throw it away and hope it doesn't happen a second time? [09:29] mmm, mmm ... [09:29] mmm [09:29] I'm having conflicts in my head [09:30] zyga: just push --force [09:46] mborzecki: getting back to runuser-vs-sudo, I'll just add a check and if runuser isn't there, try to use sudo instead [09:47] zyga: i'm going to take a break, and go do some physio; if there's anything I should do with this trusty vm let me know otherwise i'll be killing it when i get back [09:48] Chipaca: ack [09:49] mborzecki: ah, as I said, just an idea, might be too much of a pain to do quickly now [09:50] it might be easier to have a copy of the regexp for now [09:50] pedronis: interesting idea nonetheless, but i think it's more of a followup material [09:51] pedronis: i've added snap/name package and moved some validation code there [09:51] pedronis: could be beneficial in the long run [09:52] PR snapd#5951 closed: spread-shellcheck: fix interleaved error messages, tweaks [09:52] ogra: hey! Should I kick new pi3 stable images now? [09:54] sil2100: how are things looking on the pi3b+? anything I can/should test? [09:56] Chipaca: I'm inclined to merge 5944 and just see what will happen in adt [09:56] Chipaca: the only open question was slow machines here [09:56] Chipaca: and we will get tests on the pi [09:58] PR snapd#5940 closed: store: speedup unit tests [10:03] PR snapd#5917 closed: cmd/snap: attempt to start the document portal if running with a sess… [10:13] pedronis: hey, can you re-review #5952 when you have a moment? [10:13] PR #5952: tests/ifacestate: moved asserts-related mocking into helper [10:21] sil2100, yeah ... saw your mail, note that pi2 and dragonboard need updating too [10:22] mvo, at least core 16 edge seems to be fine on pi3 b+ here [10:22] (and after the rebuild also stable) [10:25] PR snapcraft#2327 closed: pluginhandler: remove prepare, build and install scriptlets [10:27] ogra: interessting, I had trouble with uc18, I will dig into it [10:28] mvo, what kind of trouble ? [10:28] booting should generally work [10:28] ogra: yeah booting is fine, I had no network [10:29] (not sure about preipherials with the 4.15 kernel, havent tested with it, but 4.4 is definitely fine, i'm just using it here on a b+) [10:30] ogra: ok, cool [10:31] PR snapcraft#2332 closed: waf plugin: support for bases [10:35] ppisati: hey, with uc18 and kernel 4.15 from the snap I have no networking on my pi3 b+. do you have any suggestions for me how to debug this? does 4.15 work on classic ubuntu with the 3b+? [10:36] mvo, you said /proc/net/dev shows them ... sounds less like a kernel issue then [10:37] PR snapcraft#2333 closed: catkin, catkin-tools: add support for bases [10:37] PR snapd#5871 closed: snapstate: only report errors if there is an actual error [10:38] ogra: yeah, they are visible but not connected, neither wifi nor wired [10:38] right, but the modules seem to load and init the HW ... [10:39] which makes it sound suspiciously like userspace [10:39] ogra: maybe, the same image works on the pi3 (without b+) as a dateapoint [10:40] well, they have the same wifi AFAIK ... but the b+ has a different ethernet NIC [10:40] pedronis: i've pushed a fix with copied snap name validation, but if you'd like to entertain the idea of a separate package, I did a quick implementation here: https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/validate-name-separate-package [10:41] so at leat wifi should work the same as in the normal pi3 [10:41] mborzecki: fwiw (without having looked at the package you just linked to) I like the idea of a snap/validate package [10:41] pedronis: i actually sort of like it, probably needs some tweaking still, but could be interesting [10:42] mvo: snap/validate may be harder because some validation code touches Info and inside structs directly, so Info would have to be defined elsewhere too [10:42] mvo: that PoC is a snap/name with name validation code pulled out, so that you could import it safely in assserts [10:43] mborzecki: aha, I see [10:43] mvo: in that sense it's mostly the validation functions which are pure and take plain arguments [10:44] * mvo nods [10:45] mvo: yes, it works [10:45] mvo: let me dig out my board and test it [10:46] ppisati: ok, thank you. I guess I need to compare dtb versions and all that to see whats going on? [10:46] ppisati: pardon my ignorance, can I just download an armhf bionic image to test this? or will I need to grab a special ubuntu image somewhere? [10:48] actually maybe my pi3 b+ is just broken, I need to test for this as well [10:48] mvo: afaik foundation never produced a rpi3(b+) image, so you probably need to roll your own [10:49] mvo: from time to time i build some classic images just for debugging, let me find one that works [10:50] ta [10:51] mvo, just use a core 16 edge to verify the HW [10:53] Chipaca: can you do a quick pass over https://github.com/snapcore/snapd/pull/5946 again? [10:53] PR #5946: cmd/snap: unhide --name parameter to snap install, tweak help message [10:55] mvo,hello [10:55] mvo, about sru validation [10:55] ogra: sounds sensible [10:55] cachio: hey [10:55] mvo, I have seen some errors which could be related to the snapd.socket which I mentioned yesterday [10:55] https://paste.ubuntu.com/p/2Nyq9GtppF/ [10:57]