| mup | PR snapcraft#2468 opened: [WIP] many: support for stage-snaps <do-not-merge-yet> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2468> | 01:15 |
|---|---|---|
| zyga | Good morning | 06:26 |
| === doko_ is now known as doko | ||
| zyga | hello mvo | 08:04 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | heyas | 08:09 |
| zyga | hey, how are you? | 08:10 |
| zyga | https://github.com/opencontainers/runc/commit/0a8e4117e7f715d5fbeef398405813ce8e88558b is fun | 08:14 |
| * dot-tobias says hi | 08:18 | |
| pstolowski | hey zyga, i'm fine, thanks, you? wife and baby back home? | 08:24 |
| zyga | pstolowski: yes, we are all home now :-) | 08:24 |
| pstolowski | great :) | 08:26 |
| mvo | zyga: yay, great news! | 08:27 |
| mvo | pstolowski: and good morning to you as well | 08:27 |
| mvo | and hello dot-tobias | 08:27 |
| pstolowski | hey mvo! | 08:38 |
| pstolowski | i feel like i'm ready to tackle selinux PRs today | 08:39 |
| pedronis | mvo: hi, I landed a couple things that were green etc and seemed innocent enough, hope it's ok | 08:40 |
| mvo | pedronis: yeah, that sounds good | 08:43 |
| === ricab is now known as ricab|bbl | ||
| pedronis | mvo: Chipaca has a couple PRs that need 2nd reviews | 10:03 |
| Chipaca | yes, yes I do | 10:03 |
| pedronis | Chipaca: one has a couple nitpicks from me as well | 10:04 |
| Chipaca | pedronis: yes. I will address them, but am waiting for a review | 10:04 |
| Chipaca | maybe i should say as much | 10:04 |
| mup | PR snapd#6492 opened: snapstate: restart into the snapd snap on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/6492> | 10:08 |
| mvo | pedronis: good timing, just finished my current task, I have a look now | 10:08 |
| mvo | Chipaca: 6034 and 6356? | 10:09 |
| Chipaca | mvo: ye | 10:09 |
| === ricab|bbl is now known as ricab_ | ||
| pedronis | mvo: I answered a couple of nitpicks for Chipaca | 11:05 |
| mvo | pedronis: ta | 11:06 |
| === sgclark is now known as sgmoore | ||
| pedronis | mvo: what can we do about https://github.com/snapcore/snapd/pull/6252 it seems to have hit some weirdness where now there's a lot of conflicts ? | 11:46 |
| mup | PR #6252: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6252> | 11:46 |
| mvo | pedronis: mbozecki was looking at the test, let me see | 11:47 |
| mvo | pedronis: uh, I think ken has pushed something incorrec,t it says 10k+ commits | 11:48 |
| mvo | pedronis: this needs some manual surgery it seems, I can look at this after lunch | 11:50 |
| Chipaca | zyga: is #1814450 something you know about? | 12:20 |
| mup | Bug #1814450: subsync - error: signal: segmentation fault <snapd:New> <https://launchpad.net/bugs/1814450> | 12:20 |
| zyga | Chipaca: the bug in general, no | 12:21 |
| Chipaca | zyga: the 'annot use "/snap/gtk-common-themes/818/share/icons/Suru" as bind-mount source: not a directo'? | 12:21 |
| zyga | https://gitlab.gnome.org/Community/Ubuntu/gtk-common-themes/issues/1 | 12:21 |
| * Chipaca is bad at cut-n-paste | 12:21 | |
| zyga | that's been open for a while | 12:21 |
| zyga | I meant to ping will about it yesterday but then the return happened | 12:22 |
| Chipaca | zyga: aha! i'll update the bug with this info | 12:22 |
| mup | PR snapd#6493 opened: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by mvo5> <https://github.com/snapcore/snapd/pull/6493> | 12:22 |
| Chipaca | abeato: ping | 12:23 |
| Chipaca | wait, probably unping | 12:23 |
| Chipaca | yeah, wrong person, sorry | 12:23 |
| zyga | kenvandine: hey, can we bump https://gitlab.gnome.org/Community/Ubuntu/gtk-common-themes/issues/1 somehow? | 12:26 |
| Chipaca | pstolowski: got a sec? | 12:27 |
| mup | Issue # closed: core18#56, core18#86, core18#89, core18#117 | 12:31 |
| mup | PR # closed: core18#43, core18#63, core18#72, core18#90, core18#98 | 12:31 |
| pstolowski | Chipaca: in 15 | 12:31 |
| mup | Issue # opened: core18#56, core18#86, core18#89, core18#117 | 12:32 |
| mup | PR # opened: core18#43, core18#63, core18#72, core18#90, core18#98 | 12:32 |
| abeato | Chipaca, haha, nw | 12:34 |
| * Chipaca ⇝ lunch | 12:43 | |
| === ricab_ is now known as ricab | ||
| === ricab__ is now known as ricab|laptop | ||
| Chipaca | mvo: #1814484 should be fixed, right? | 12:51 |
| mup | Bug #1814484: wal-e no longer works as of snapd 2.37 <canonical-is> <PostgreSQL Charm:Confirmed> <snapd:New> <https://launchpad.net/bugs/1814484> | 12:51 |
| Chipaca | popey: might #1814242 be something you can look into? | 12:52 |
| mup | Bug #1814242: Remmina snap package review <snapd:New> <https://launchpad.net/bugs/1814242> | 12:52 |
| popey | thanks Chipaca will take a look | 12:53 |
| Chipaca | mvo: did the latest change wrt --classic for strict land in .2? | 12:53 |
| pedronis | Chipaca: yes | 12:54 |
| Chipaca | degville: when you have a bit, could you see if you have suggestions wrt #1811276 ? | 12:57 |
| mup | Bug #1811276: Installing an already-installed snap docs could be more helpful <snapd:Confirmed> <https://launchpad.net/bugs/1811276> | 12:57 |
| degville | Chipaca: yep, or course. | 12:57 |
| Chipaca | pedronis: #1811063 for your consideration | 12:58 |
| mup | Bug #1811063: "snap refresh" does not report failure to update because snap switched to classic confinement <snapd:New> <Snappy:Invalid> <https://launchpad.net/bugs/1811063> | 12:59 |
| Chipaca | pedronis: also #1810982 | 12:59 |
| mup | Bug #1810982: Preseeding Snaps Broken for Trusty <snapd:New> <https://launchpad.net/bugs/1810982> | 12:59 |
| diddledan | did I share this in here yet? https://snapstats.org/ | 13:00 |
| pedronis | Chipaca: isn't the first bug a matter of using warnings appropriately? | 13:00 |
| pedronis | the user marked it invalid | 13:00 |
| Chipaca | pedronis: invalid in snappy, not in snapd | 13:00 |
| Chipaca | pedronis: I think so, warnings would make it better | 13:00 |
| Chipaca | pedronis: I'll explain on the bug | 13:01 |
| Chipaca | pedronis: and assign it to me because why not | 13:01 |
| pedronis | the trusty one we are aware from other channels, nobody had time to dig into it | 13:01 |
| pedronis | so far | 13:01 |
| Chipaca | pedronis: ah ok | 13:02 |
| Chipaca | pedronis: maybe tweak the bug so that much is clear? | 13:02 |
| pstolowski | Chipaca: hey, sorry, had to bring my daughter from school, i'm in now, what's up? | 13:02 |
| Chipaca | pstolowski: I've got a question about 'snap get' vs 'snapctl get', and thought you might know | 13:03 |
| Chipaca | pstolowski: 'snapctl get' always returns a document? | 13:03 |
| Chipaca | pstolowski: or is it only if the thing is documentish | 13:03 |
| Chipaca | ah, yes | 13:03 |
| Chipaca | pstolowski: so, sorry, my actual question is: why don't we support a bare -d in snapctl get? any strong reason? | 13:04 |
| pedronis | mvo: are you ok to get https://bugs.launchpad.net/snapd/+bug/1810982 assigned, it involves livecd-rootfs which I don't think anybody else is familiar with | 13:06 |
| mup | Bug #1810982: Preseeding Snaps Broken for Trusty <snapd:New> <https://launchpad.net/bugs/1810982> | 13:06 |
| === Saviq is now known as ricab|test | ||
| === ricab|test is now known as Saviq | ||
| pstolowski | Chipaca: hmm, i'm looking at ctlcmd/get.go and it has '... short:"d" description:"always return document, even with single key"' | 13:09 |
| pedronis | pstolowski: I think Chipaca is asking about "snapctl get -d" with no key | 13:10 |
| pedronis | which I think maybe you mentioned in your open PR | 13:10 |
| pstolowski | pedronis: ah | 13:11 |
| Chipaca | yep, -d with no key | 13:12 |
| Chipaca | #1814876 | 13:13 |
| mup | Bug #1814876: snapctl get -d doesn't allow returning full config <snapd:New> <https://launchpad.net/bugs/1814876> | 13:13 |
| pstolowski | Chipaca: right. I *think* (i wasn't yet in the team when snapctl was implemented) the idea was the "snap get" is user facing tool, so it's desirable to return entire document to discover options; snapctl is queried programatically, the snap knows its options so it just retrieves specific keys | 13:14 |
| pstolowski | Chipaca: i vaguely remember hearing that reasoning from someone.. but it's possible i made it up ;) | 13:17 |
| Chipaca | I agree the primary use case is that one, but developers still like to debug their things :-) | 13:18 |
| Chipaca | allegedly | 13:18 |
| pstolowski | Chipaca: not disagreeing | 13:19 |
| dot-tobias | Is it possible to delete old revisions of a snap in the store? | 13:20 |
| === ricab is now known as ricab|lunch | ||
| pedronis | Chipaca: pstolowski: fwiw I'm not against making -d without key work until we have finished other stuff. I think arbitrary differences between snapctl and snap are mostly not worth it | 13:22 |
| pedronis | s/until/after/ | 13:22 |
| pstolowski | +1 | 13:24 |
| diddledan | dot-tobias: no, you can only remove them from any channels | 13:43 |
| dot-tobias | diddledan: ok, thanks! | 13:44 |
| pedronis | pstolowski: I did a first pass over #5962, didn't quite look at everything yet | 13:47 |
| pedronis | some questions there | 13:47 |
| mup | PR #5962: ifacestate/hotplug: hotplug handlers <Complex> <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5962> | 13:47 |
| pstolowski | pedronis: thanks | 13:47 |
| pstolowski | cachio: proposed a trivial PR https://github.com/sergiocazzolato/snappy-qa-jobs/pull/2 | 13:51 |
| mup | PR sergiocazzolato/snappy-qa-jobs#2: Added doc about SPREAD_TESTS and SKIP_TESTS vars <Created by stolowski> <https://github.com/sergiocazzolato/snappy-qa-jobs/pull/2> | 13:51 |
| pedronis | mvo: should we close #6252 now that you made 6493 ? | 13:52 |
| mup | PR #6252: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6252> | 13:52 |
| pedronis | pstolowski: also reviewed #6490 with a small comment | 13:56 |
| mup | PR #6490: tests: fix NFS home mocking <Created by stolowski> <https://github.com/snapcore/snapd/pull/6490> | 13:56 |
| cachio | pstolowski, nice, I'll take a look | 13:56 |
| cachio | thank | 13:57 |
| mvo | pedronis: yeah, let me close it now, its not useful in its current form | 13:58 |
| zyga | mvo: hey, there are some milestones on https://launchpad.net/snapd/trunk that feel stale, would you mind if I closed them? (2.36.x) | 13:58 |
| pstolowski | pedronis: thanks | 13:58 |
| mup | PR snapd#6252 closed: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6252> | 13:59 |
| kenvandine | mvo: thanks! | 14:00 |
| mvo | kenvandine: if you could quickly double check | 14:00 |
| kenvandine | mvo: looking | 14:01 |
| zyga | oh | 14:02 |
| zyga | standup | 14:02 |
| mvo | kenvandine: thanks | 14:02 |
| zyga | kenvandine: hey :) | 14:03 |
| zyga | kenvandine: I sent a ping earlier today, not urgent but please confirm that you saw it | 14:03 |
| kenvandine | zyga: i did see it | 14:03 |
| kenvandine | i think jamesh might have submitted a fix to Yaru instead | 14:04 |
| zyga | great, thank you | 14:04 |
| zyga | kenvandine: I think it's still out in the wild so I wonder if it's a matter of publishing something to stable | 14:04 |
| kenvandine | zyga: that should be fixed by https://gitlab.gnome.org/Community/Ubuntu/gtk-common-themes/merge_requests/8 | 14:16 |
| zyga | should the issue be closed then? | 14:16 |
| zyga | people still report it | 14:17 |
| kenvandine | it's still waiting for feedback | 14:19 |
| t1mp | hello | 14:41 |
| t1mp | looks like snapcraft broke backwards compatibility for me, without warning | 14:41 |
| t1mp | Failed to get part information: Cannot find the definition for part 'desktop-gtk3', required by part 'app'. | 14:41 |
| t1mp | Remote parts are not supported with bases, so make sure that this part is defined in the `snapcraft.yaml`. | 14:41 |
| t1mp | the same snapcraft.yaml was working before | 14:41 |
| popey | snapcraft 3.x did indeed disable remote parts | 14:42 |
| t1mp | also, version: 2 is no longer accepted (but version: "2") works | 14:42 |
| t1mp | is there some manual on how to migrate? What should I use instead of the remote part? | 14:43 |
| diddledan | 2 is a number. '2' is a string. if it accepted 2 before that was a bug | 14:43 |
| popey | t1mp: https://paste.ubuntu.com/p/jdMWkMJKhF/ | 14:43 |
| * diddledan pastes his link again for anyone who missed it - go look :-p https://snapstats.org/ | 14:45 | |
| t1mp | popey: thanjsk! | 14:46 |
| t1mp | -j | 14:46 |
| popey | njp | 14:46 |
| diddledan | :-p | 14:46 |
| diddledan | popey: yeejit :-p | 14:46 |
| t1mp | why do I need to remove the base: core18 line? | 14:47 |
| t1mp | that's what I'm using for my snap too | 14:47 |
| popey | because snapcraft define wont work with it | 14:47 |
| popey | you dont need to remove it in *your* yaml, only in the tmp one | 14:47 |
| diddledan | it won't expand the definition with it in place - the base: core18 triggers snapcraft to use new features and remove old ones | 14:48 |
| === ricab|lunch is now known as ricab | ||
| diddledan | of course you can add it back as soon as you've run `snapcraft define` | 14:49 |
| t1mp | ok | 14:49 |
| * cachio lunch | 14:54 | |
| t1mp | popey, diddledan: okay, thanks. I'm rebuilding my snaps (with snapcraft 3.. and 2 on jenkins. I hope that one still works after my changes). | 14:55 |
| t1mp | I get some errors, | 14:57 |
| t1mp | Staging desktop-gtk3 | 14:57 |
| t1mp | rm: cannot remove '/var/cache/apt/archives/partial/*.deb': Permission denied | 14:57 |
| t1mp | but the pull seems to continue after that | 14:57 |
| t1mp | I require coffee. brb | 14:58 |
| t1mp | An error occurred when trying to execute 'sudo -i snapcraft prime' with 'multipass': returned exit code 2. | 15:03 |
| t1mp | ah. I have a version-script, and I guess before snapcraft wasn't building the stuff in a vm. Now it is and my script is not available there. | 15:05 |
| * zyga is eating lunch | 15:20 | |
| mup | Issue # closed: core18#56, core18#86, core18#89, core18#117 | 15:20 |
| mup | PR # closed: core18#43, core18#63, core18#72, core18#90, core18#98 | 15:20 |
| mup | Issue # opened: core18#56, core18#86, core18#89, core18#117 | 15:21 |
| mup | PR # opened: core18#43, core18#63, core18#72, core18#90, core18#98 | 15:21 |
| diddledan | mup seriously needs educating about what "closing" means - it keeps on with things like ^^^^^ where it says "foo is closed" immediately followed by "foo is new and just been opened!!!! OMGZOR IT'S BRAND NEW!!!!" | 15:22 |
| Chipaca | diddledan: github api hiccups | 15:24 |
| Chipaca | and mup-side state | 15:24 |
| Chipaca | afaik | 15:24 |
| Chipaca | ikn | 15:24 |
| Chipaca | ikr? | 15:24 |
| Chipaca | wtf | 15:24 |
| diddledan | oh dear. stack smashing in a quit message? | 15:25 |
| diddledan | ref: 15:25:04 ⇐ mdeslaur quit (~mdeslaur@ubuntu/member/mdeslaur) Quit: *** stack smashing detected *** | 15:25 |
| diddledan | that sounds nasty | 15:25 |
| pstolowski | pedronis: re your comment about why do i only log error on from addHotplugSeqWaitTask(chg, key) - it's a good point - i wonder what's the right thing to do; is chg.Abort() the right way of dealing with this? we have change and tasks already created in the state, but we shouln't run them if seq task couldn't be added | 15:34 |
| pedronis | pstolowski: need to think a bit | 15:35 |
| pedronis | pstolowski: I think is doing things with a patter that we don't use | 15:35 |
| pedronis | *pattern | 15:35 |
| pedronis | pstolowski: we usually have all the tasks, and then add them to the change | 15:37 |
| pedronis | pstolowski: we might have to tweak the helper | 15:38 |
| pstolowski | pedronis: btw, error here is if things go really bad (failure other than NoState from st.Get("hotplug-seq"..)) | 15:38 |
| pedronis | pstolowski: I understand but see my comment here | 15:38 |
| pstolowski | pedronis: i'd move allocHotplugSeq out of the helper, so it needs to be allocated by the caller and passed to the helper. that way it can be allocated (or fail) early before creating change and tasks. wdyt? | 15:44 |
| pedronis | pstolowski: yes, something like that | 15:45 |
| pedronis | pstolowski: we should follow other places and create the change last | 15:46 |
| pstolowski | pedronis: i see | 15:46 |
| Chipaca | fun things to do: run out of space on /tmp 🗹 | 16:22 |
| mup | PR snapd#6490 closed: tests: fix NFS home mocking <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6490> | 16:22 |
| pedronis | Chipaca: just a reminder that #6034 description/commit needs updating, it still using the original names of things | 16:27 |
| mup | PR #6034: many: save media info when installing, show it when listing <Squash-merge> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6034> | 16:28 |
| Chipaca | pedronis: thanks | 16:28 |
| Chipaca | pedronis: I'm waiting for an answer from mvo, but I'd already forgotten about the desc | 16:28 |
| pedronis | Chipaca: about the test? | 16:29 |
| Chipaca | pedronis: yes | 16:33 |
| Chipaca | pedronis: (description updated) | 16:33 |
| pedronis | thx | 16:37 |
| pstolowski | pedronis: thanks for catching a few issues in the hotplug PR; i think i've addressed all your 1st pass comments | 17:20 |
| === pstolowski is now known as pstolowski|afk | ||
| mup | PR snapd#6493 closed: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6493> | 18:56 |
| === JanC_ is now known as JanC | ||
| === blackboxsw_ is now known as blackboxsw | ||
| === hunterk_ is now known as hunterk | ||
| === bashfulrobot_ is now known as bashfulrobot | ||
| pedronis | mvo: I looked again at #6418, I am a bit confused because the code you changed in snap-confine looks like it was originally buggy? | 19:07 |
| mup | PR #6418: many: allow core as a fallback for core16 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6418> | 19:07 |
| mvo | pedronis: thanks, let me check | 19:07 |
| mvo | pedronis: I remember I fixed something in there, yes | 19:07 |
| mvo | pedronis: let me check, you mentioned the new code looks also a bit strange, let me open it | 19:08 |
| pedronis | mvo: mind not buggy, just strange | 19:08 |
| pedronis | the new code | 19:08 |
| * mvo nods and looks | 19:08 | |
| mvo | pedronis: yeah, the triple access is strange, I have a look what can be done | 19:25 |
| pedronis | mvo: going to eod, I'll continue with your other PRs in the morning | 19:31 |
| mvo | pedronis: thank you! | 19:31 |
| jdstrand | mvo: hey, I can't recall the details, but I feel like you said something like this would break snapd: https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/362906 | 19:45 |
| jdstrand | mvo: (server team is adding a syscall to bionic's libseccomp) | 19:45 |
| mvo | jdstrand: thanks, let me check | 19:57 |
| mvo | jdstrand: hm, I don't recall having said this, zyga was working on statx, maybe he remembers more -^ | 20:00 |
| jdstrand | mvo: I thought you said that the act of adding syscalls to trusty's libseccomp complicated things for you | 20:10 |
| mup | PR snapcraft#2467 closed: [legacy] ruby plugin: support new download URL <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2467> | 20:11 |
| jdstrand | mvo: or maybe that was vivid. like I said, I do not recall the details :) | 20:14 |
| mvo | jdstrand: I don't remember .( I will double check with -proposed tomorrow | 20:21 |
| === gurmble is now known as grumble | ||
| mup | PR snapcraft#2469 opened: cli: clean up snapcraft push output <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2469> | 20:38 |
| mwhudson | hm i want to capture communication between snap and snapd for testing later | 21:02 |
| mwhudson | i wonder how many recording proxies support unix sockets :) | 21:02 |
| mwhudson | and then i guess i'd need to coerce snapd to talk to it anyway | 21:03 |
| mwhudson | er snap | 21:03 |
| Chipaca | mwhudson: you can have snapd take arbitrary sockets by tweaking its .socket unit | 21:04 |
| mwhudson | hmm | 21:04 |
| Chipaca | mwhudson: even, gasp, ip | 21:04 |
| Chipaca | mwhudson: (but good luck getting unix credentials) | 21:05 |
| === epod is now known as luk3yx | ||
| mwhudson | probably easier just to hack my own snapd binary that writes all requests and responses somewhere? | 21:05 |
| mwhudson | argh snap binary | 21:05 |
| Chipaca | mwhudson: either would work -) | 21:06 |
| mwhudson | i can't type 'snap' without the 'd' apparently | 21:06 |
| Chipaca | mwhudson: I'm going to write a tool and call it 'snadp', just for you | 21:07 |
| mwhudson | Chipaca: i hope you feel bad | 21:07 |
| Chipaca | pretty good actually | 21:07 |
| Chipaca | my mum sent triple-choc brownies | 21:07 |
| mwhudson | i guess this Client.Hijack method might be useful for this | 21:15 |
| mwhudson | other question | 21:16 |
| mwhudson | is there a snapd api i can use to ask if there is an update available for a particular snap? | 21:16 |
| mwhudson | iirc i could only ask about all installed snaps which i guess is ok too | 21:17 |
| mwhudson | basically i'm working on adding support for triggering a self refresh to subiquity and am wondering about how to test it | 21:17 |
| Chipaca | mwhudson: snap refresh --list ? | 21:24 |
| Chipaca | mwhudson: (sorry I didn't see your question) | 21:25 |
| Chipaca | mwhudson: wrt logging, I'd look at (*client.Client).do | 21:26 |
| Chipaca | actually, this sounds useful | 21:27 |
| * Chipaca looks | 21:27 | |
| mwhudson | i would actually like it for my other thing so i can see which api snap refresh --list is hitting :) | 21:27 |
| Chipaca | mwhudson: http snapd:///v2/find select==refresh | 21:29 |
| mwhudson | Chipaca: thanks | 21:29 |
| Chipaca | mwhudson: niets te danken | 21:29 |
| Chipaca | mwhudson: but | 21:32 |
| Chipaca | mwhudson: snapd is already logging that :-) | 21:32 |
| Chipaca | Feb 12 21:32:20 fleet snapd[6262]: daemon.go:296: DEBUG: pid=26464;uid=1001;socket=/run/snapd.socket; GET /v2/find?select=refresh 244.125698ms 200 | 21:32 |
| Chipaca | I thought you were looking at POSTs | 21:33 |
| mwhudson | only if you turn up logging right? | 21:33 |
| Chipaca | mwhudson: just SNAPD_DEBUG=1 | 21:34 |
| Chipaca | yes | 21:34 |
| Chipaca | DEBUG | 21:34 |
| mwhudson | but yes i want post and response bodies in general | 21:34 |
| Chipaca | ok, I'll play with that in a bit | 21:34 |
| mup | PR snapd#6494 opened: interfaces/builtin/udev: add spec to disable udev + device cgroup <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6494> | 21:34 |
| mwhudson | would be great | 21:34 |
| mwhudson | i can hack something for my own use but i'm sure your version would be cleaner :) | 21:35 |
| Chipaca | mwhudson: http://paste.ubuntu.com/p/RN5xYkwf3c/ | 21:45 |
| Chipaca | mwhudson: that still won't log the body of the request, but I can add that if this would work | 21:45 |
| Chipaca | I also have a delogger.py you might find useful | 21:45 |
| Chipaca | mwhudson: https://gist.github.com/chipaca/5d0f0e2b7fecd2df87f25b798a6c6537 | 21:46 |
| Chipaca | delog.py | 21:46 |
| mwhudson | +Key: "SNAPD_DEBUG_HTTP", | 21:57 |
| mwhudson | -D? | 21:57 |
| mwhudson | but thanks | 21:57 |
| mwhudson | Chipaca: where would that log to? | 22:03 |
| Chipaca | mwhudson: yeah, it's not pretty | 22:03 |
| Chipaca | that logs to the log :-/ | 22:04 |
| Chipaca | as in | 22:04 |
| Chipaca | SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=7 /tmp/snap refresh --list | 22:04 |
| Chipaca | *** here | 22:04 |
| Chipaca | 2019/02/12 21:44:33.361905 logger.go:67: DEBUG: > "GET /v2/find?q=&select=refresh HTTP/1.1\r\nHost: localhost\r\nUser-Agent: | 22:04 |
| Chipaca | etc etc | 22:04 |
| mwhudson | oh you need SNAPD_DEBUG=1 as well | 22:05 |
| Chipaca | there's probably some standard for logging http requests that is weeping | 22:05 |
| Chipaca | also whoa what's with tht funky date format | 22:15 |
| * Chipaca hopes it'll make sense in the morning | 22:15 | |
| Chipaca | o/ | 22:16 |
| kyrofa | Hey jdstrand, how is the docker (not docker support) interface being used these days? Reading the code, it kinda looks like I can't even install a snap that plugs it, is that true? (allow-installation: false) | 22:37 |
| jdstrand | kyrofa: you can do an unasserted install with --dangerous. you need a snap decl to distribute via the store | 22:38 |
| jdstrand | the docker socket gives you device ownership, just like docker-support since it gives you access to the socket whose listener has docker-support and there aren't acls on the api | 22:39 |
| kyrofa | Ah, so nothing random folks can really use, then | 22:40 |
| jdstrand | correct | 22:40 |
| jdstrand | I mean, if it is legitimate use, that is one thing | 22:41 |
| jdstrand | eg, k8s or something, but it is superprivileged | 22:42 |
| kyrofa | I just want to be able to fire up a docker container from within a confined snap. Bundling docker would require super plugs, and it seems using docker ALSO requires super plugs | 22:42 |
| kyrofa | Decent confinement would require mediation, basically? | 22:43 |
| ijohnson_ | kyorfa: the "designed" way to do this with the docker snap is to plug the docker:docker-executables slot in your snap and then use the docker binary from the docker snap in your snap | 22:43 |
| ijohnson_ | kyrofa: ^ | 22:43 |
| kyrofa | ijohnson_, what if I want to use the API instead of shelling to a binary? | 22:44 |
| ijohnson_ | then you would plug docker:docker-daemon also slotted by the docker snap (which is the "docker" interface which allows access to the unix socket) | 22:44 |
| kyrofa | That one isn't a super plug? | 22:45 |
| ijohnson_ | no, the "docker" interface is explicitly not slotted by the core snap, only docker-support is slotted by the core snap | 22:46 |
| ijohnson_ | as jdstrand pointed out you will have a hard time getting an auto-connection for the docker-support interface if you aren't actually docker or k8s, etc. | 22:46 |
| ijohnson_ | this is the "designed" way to launch docker containers from a different snap, which is admittedly quite awkward and not well supported at the moment | 22:47 |
| ijohnson_ | it should work though, please let me know if it doesn't | 22:47 |
| kyrofa | ijohnson_, who is maintaining that snap these days, you? | 22:47 |
| jdstrand | it is super | 22:48 |
| jdstrand | err | 22:48 |
| jdstrand | it is super for the slot | 22:49 |
| jdstrand | but the docker snap has a snap decl that allows connecting to it | 22:50 |
| * jdstrand forgot about that | 22:50 | |
| jdstrand | so if you use the docker snap, you can plugs it | 22:50 |
| jdstrand | but it won't autoconnect | 22:51 |
| kyrofa | Heh, yeah I didn't even think to see if core provided a docker slot, of course it doesn't | 22:51 |
| jdstrand | someone else couldn't slots docker or plugs it | 22:52 |
| kyrofa | Indeed, that makes sense | 22:52 |
| ijohnson_ | hey also jdstrand while you're here talking about the docker snap, there was a CVE published yesterday concerning a bad actor being able to overwrite the runc binary which docker runs as root to start containers. The snap wasn't affected because the runc binary is mounted read-only (cause squashfs), but looking through the apparmor we allow writes to /proc/[0-9]*/fd/[0-9]* (which is what I think /proc/self/exe resolves to | 22:52 |
| ijohnson_ | anyways) | 22:52 |
| ijohnson_ | is mounting as read-only the only way we can prevent similar attacks overwriting a binary using /proc/self/exe? | 22:53 |
| jdstrand | so, I'll revise my answer. if you have the docker snap installed, you can plugs docker and manually connect and go on your way | 22:53 |
| jdstrand | ijohnson_: apparmor protects us as well | 22:53 |
| jdstrand | it is a symlink so it resolves to the binary and the policy doesn't allow arbitrary writes | 22:54 |
| ijohnson_ | hmm when I was looking yesterday it seemed to allow it | 22:54 |
| ijohnson_ | err wait you mean don't allow arbitrary writes to $SNAP ? | 22:54 |
| jdstrand | ijohnson_: as for programmatically fixing this for a container management system that doesn't use apparmor, you can do something like what the runc devs did | 22:54 |
| jdstrand | they have an ingenious approach. I suggest reading https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/runC | 22:55 |
| ijohnson_ | good to know, thanks for the link | 22:55 |
| ijohnson_ | I meant that https://github.com/snapcore/snapd/blob/master/interfaces/apparmor/template.go#L306-L313 allows writes to /proc/*/fd/* doesn't it? | 22:55 |
| jdstrand | ijohnson_: if you can write to what /proc/self/exe is pointing to, then you can use the same technique. but, you don't need to use the technique because you already have write access to it. the difference is that with runc you were able to escalate privileges and write to somewhere you weren't supposed to | 22:57 |
| ijohnson_ | ah I see, okay | 22:58 |
| ijohnson_ | thanks for confirming | 22:58 |
| jdstrand | so for snapd, it isn't an issue on several fronts. $SNAP is ro squashfs, apparmor doesn't allow it, apparmor doesn't allow strict mode snaps to write to /var/lib/snapd/hostfs, etc. in forced devmode, it is wide open. we aren't providing file restrictions so no priv escalation | 22:59 |
| ijohnson_ | yep that all makes sense now | 22:59 |
| jdstrand | ijohnson_: to specifically answer your /proc/*/fd/* question. we do allow reads there and writes to [0-9]*, but importantly, those are symlinks that apparmor will resolve | 23:08 |
| ijohnson_ | ack | 23:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!