| ijohnson[m] | cachio: thanks | 01:00 |
|---|---|---|
| mardy | 'morning! | 04:43 |
| mborzecki | morning | 05:24 |
| mborzecki | mardy: heya | 05:24 |
| pstolowski | morning | 06:01 |
| mardy | pstolowski: hi! | 06:07 |
| pstolowski | mardy: hey, a few minor suggestions to start services PR | 06:46 |
| mborzecki | pstolowski: hey | 06:51 |
| zyga-mbp | good morning | 07:14 |
| pstolowski | hey zyga-mbp | 07:14 |
| mborzecki | mvo: one step closer https://github.com/snapcore/snapd/pull/10510 | 07:23 |
| mvo | mborzecki: \o/ thanks. let me look | 07:24 |
| mvo | mborzecki: this looks very good | 07:36 |
| mborzecki | mvo: as it says in the descritpion, the bit to restore the old model of final reseal fails is missing still | 07:37 |
| mborzecki | we didn't really have to do it until now, as remodelCtx.Finish() was end of the road for this change and could not fail, but now we have one more step which can actually fail | 07:38 |
| mborzecki | well, unlikely but still | 07:38 |
| mvo | mborzecki: *nod* | 07:39 |
| pedronis | hello, https://github.com/snapcore/snapd/pull/10376 needs a 2nd review, it's simple-ish | 07:44 |
| mardy | pedronis: +1 | 07:47 |
| pedronis | thx | 07:48 |
| pstolowski | i'm still looking at it | 07:48 |
| pstolowski | 1 minor comment so far | 07:49 |
| pedronis | pstolowski: could you do a 2nd review of https://github.com/snapcore/snapd/pull/10437 when you have a bit of time as you are a bit familiar with quotas | 07:49 |
| pstolowski | pedronis: will do | 07:49 |
| pedronis | thx | 07:50 |
| * pstolowski physio | 07:52 | |
| mardy | mvo: the microk8s user/group did not make it in time for 2.51.2, did it? | 08:24 |
| mvo | mardy: it did not | 08:24 |
| mvo | mardy: was it marked 2.51? | 08:24 |
| mvo | (also in a meeting) | 08:24 |
| mvo | (sry!) | 08:24 |
| mardy | mvo: I didn't mark it in any way, at least. I'm unfamiliar with the release process. But no worries! I'll just let the microk8s people that the thing is in the master branch | 08:25 |
| mvo | mardy: yeah, edge should be fine | 08:25 |
| mvo | mardy: we can chat after my meeting | 08:25 |
| pstolowski | re | 09:00 |
| mardy | pstolowski: re. Too bad that the domain phys.io is already taken | 09:07 |
| pstolowski | heh | 09:07 |
| pstolowski | pedronis: re validation sets asserts refresh, i think we need to refresh monitored and enforced ones separately because conflicts should prevent commit only for enforced ones, right? | 09:13 |
| pedronis | pstolowski: correct | 09:16 |
| pstolowski | ty | 09:16 |
| mardy | I'm exploring the idea of having snapd retrieve the credentials (=name, I guess) of the snap which is making a request via snapctl, and then execute a program under the snap's own confinement. Any suggestions on where in the code to look at, in case we have already something similar? | 09:26 |
| pedronis | mardy: the context ctlcmd.Run receives has that information | 09:35 |
| pedronis | mvo: I reviewed https://github.com/snapcore/snapd/pull/10264 again | 09:35 |
| pstolowski | pedronis: i proposed a draft https://github.com/snapcore/snapd/pull/10511, it is obviously missing tests. a quick look and high level feedback would be helpful | 09:50 |
| pedronis | pstolowski: thx, I'll try to look after lunch | 09:54 |
| pstolowski | thx | 09:54 |
| mvo | pedronis: thank you, excellent points | 09:56 |
| mborzecki | hmm did we land something for nested? `/bin/bash: line 109: /home/gopath/src/github.com/snapcore/snapd/tests/lib/tools/nested-state: No such file or directory` | 11:14 |
| ijohnson[m] | morning folks | 11:33 |
| ijohnson[m] | bboozzoo: I know I saw some PR's from cachio about nested stuff, not sure if they landed or not | 11:33 |
| pstolowski | hey ijohnson[m] | 11:33 |
| ijohnson[m] | o/ | 11:34 |
| pstolowski | ijohnson[m], mborzecki : https://github.com/snapcore/snapd/pull/10419 not landed yet | 11:34 |
| ijohnson[m] | pstolowski: I thought there were smaller ones too | 11:35 |
| ijohnson[m] | like this one https://github.com/snapcore/snapd/pull/10500 | 11:35 |
| ijohnson[m] | that one landed | 11:35 |
| pedronis | mvo: either I'm confused or we are getting again delta failures | 11:43 |
| ijohnson[m] | fun | 11:44 |
| pedronis | mvo: https://github.com/snapcore/snapd/pull/10376/checks?check_run_id=3017856286 | 11:44 |
| mvo | pedronis: oh no, looking | 11:45 |
| mvo | pedronis: I will raise this with the store again | 11:46 |
| pstolowski | ijohnson[m]: hmm indeed | 11:48 |
| pedronis | pstolowski: I looked at https://github.com/snapcore/snapd/pull/10511, thx | 11:58 |
| pstolowski | pedronis: thank you! | 11:58 |
| mardy | do we have any place in snapd where we are calling a process via snap-confine? | 12:00 |
| ijohnson[m] | mardy: there are other "helper" tools that snap-confine calls | 12:00 |
| zyga-mbp | mardy: directly? | 12:00 |
| ijohnson[m] | like snap-update-ns iirc | 12:00 |
| zyga-mbp | mardy IIRC we only call it via snap-run | 12:00 |
| zyga-mbp | (except in some tests perhaps) | 12:00 |
| mardy | zyga-mbp: I mean like the hooks: AFAIU they are run under the snap confinment and are triggered by snapd | 12:02 |
| pstolowski | mardy: hooks also run via snap-run -> snap-confine | 12:03 |
| zyga-mbp | mardy: hooks execute through snap run | 12:04 |
| zyga-mbp | snap run --hook IIRC | 12:04 |
| pedronis | mardy: if you want to add a new variant of running things as the snap it probably needs to be added as a feature of "snap run" | 12:06 |
| zyga-mbp | mardy what are you thinking about? | 12:06 |
| pedronis | mardy: calling snap-confine from snapd directly is not something I would do | 12:06 |
| pedronis | mardy: you might need to be careful not to call something that the snap can modify or influence though, or reason that is not a problem | 12:07 |
| pedronis | mborzecki: I did a quick first pass on https://github.com/snapcore/snapd/pull/10510 | 12:08 |
| zyga-mbp | mardy: snap run provides the right input (environment) to snap-confine | 12:09 |
| mardy | zyga-mbp, pedronis: I was investigating the idea of having the mount operation (for the mount-control interface) being executed in a separate process running under the snap's own confinement. So, if the mount succeeds, we know that the client had the right permissions, and we can create the mount unit (if the mount is persistent) | 12:15 |
| zyga-mbp | mardy: hmmm | 12:15 |
| pedronis | mardy: this is complex because you need to think whether the snap can manipulate its mount namespace to cheat and make that binary return happy even when it shouldn't | 12:16 |
| zyga-mbp | mardy: that is tricky, for once, we define the confinement so it could be that we are measuring ourselves | 12:16 |
| zyga-mbp | mardy: on some systems all mount calls are allowed, so that would also be confusing as the snap would have different behavior (as in what snapd does) based on that | 12:16 |
| pedronis | mardy: I suppose you could look/have to look at the mount table after instead of trusting the return of the invocation | 12:17 |
| zyga-mbp | mardy: if anything I would do it as a function of the apparmor profile (which is an opaque text) and extend it to carry information about allowed mount calls | 12:17 |
| mardy | zyga-mbp: ah, you mean if apparmor is disabled? that's a good point | 12:17 |
| zyga-mbp | mardy: or doesn't mediate mount | 12:17 |
| zyga-mbp | mardy: then you could explicitly allow that in mount snippets and reliably test for that without doing so in the running system | 12:18 |
| pedronis | but yes, also what zyga said, on some systems we don't have apparmor, but especialyl for persistent mounts we want to follow our own constraints | 12:18 |
| mardy | pedronis: sure, that's what I meant; but now zyga-mbp raised another issue, where apparmor is either disabled or not mediating mount. I guess we would still want snapd to block the operation? | 12:18 |
| pedronis | yes, if snapd is mediating and it's about generate persistent host mounts, we don't want to allow it even on those systems | 12:19 |
| zyga-mbp | mardy: yes, then you could do that regardless of the actual sandbox being able to do that effectively | 12:19 |
| pedronis | also because the difference of behavior is too big | 12:19 |
| zyga-mbp | I agree with pedronis | 12:19 |
| pedronis | on top of the security concern | 12:19 |
| mardy | and I agree with both of you, then :-) | 12:20 |
| mardy | it's a pity, though :-) | 12:20 |
| zyga-mbp | mardy: it's a bit more complex since apparmor profile has many items inside | 12:20 |
| zyga-mbp | including sup profiles and hats | 12:20 |
| zyga-mbp | and it is unclear how to test against that as a whole | 12:20 |
| zyga-mbp | but you could do something like this | 12:21 |
| zyga-mbp | change the apparmor spec to model allowed mount operations | 12:21 |
| zyga-mbp | validate against _that_ in your logic | 12:21 |
| zyga-mbp | and replace the literal text in apparmor snippets, that describe mount calls, with generated snippets based on the allowed mount operations | 12:21 |
| zyga-mbp | this way you have the _effective_ same text of the apparmor snippet | 12:22 |
| zyga-mbp | but you can ask questions against the apparmor.Spec object | 12:22 |
| zyga-mbp | not sure if this is something you considered or if pedronis agrees, this is just my suggestion | 12:22 |
| mborzecki | pedronis: thanks | 12:22 |
| mardy | zyga-mbp: I'm afraid I don't understand your suggestion :-( What I currently have is this: https://github.com/mardy/snapd/blob/mount-control/interfaces/builtin/mount_control.go#L259 | 12:24 |
| zyga-mbp | mardy: look at interfaces/apparmor.Spec | 12:25 |
| zyga-mbp | go doc it | 12:25 |
| zyga-mbp | what if it had a Spec.IsMountAllowed(...) | 12:25 |
| zyga-mbp | that's what I'm describing | 12:25 |
| zyga-mbp | right now snapd generates the apparmor profile but the information is lost in untyped strings | 12:26 |
| zyga-mbp | I'm suggesting to change that, so for the specific case of mount rules, snapd would understand that part | 12:26 |
| zyga-mbp | do you see where this is going? | 12:26 |
| mardy | zyga-mbp: yes. OTOH, I wonder if we really want to tie it to apparmor, or have it as part of a more MAC-agnostic logic | 12:29 |
| zyga-mbp | mardy: that's a good question | 12:29 |
| zyga-mbp | mardy: it could be a separate new type of backend that really is used as input to other backends (e.g. apparmor and seccomp) | 12:30 |
| mardy | yes, that would make sense | 12:30 |
| zyga-mbp | mardy and at some point, it's all going to be landlock and eBPF :-) | 12:32 |
| mardy | ijohnson[m]: do we need to make a PR to snapcraft? I get this error if I declare the new microk8s user: "Issues while validating snapcraft.yaml: The 'system-usernames' property does not match the required schema: 'snap_microk8s' is not a valid system-username." | 12:49 |
| mardy | or maybe my declaration is wrong... | 12:53 |
| mardy | ah, I guess I need to add it here: https://github.com/snapcore/snapcraft/blob/405c576553d22be9727f681f8cda88b220b39f30/schema/snapcraft.json#L522 | 12:54 |
| ijohnson[m] | mardy yes | 12:54 |
| mardy | ijohnson[m]: I guess I can create the branch and submit a PR already - or do we need to a new snapd release carrying this change? | 12:55 |
| ijohnson[m] | mardy let's chat in the SU | 12:59 |
| mardy | ijohnson[m], pedronis: do you prefer adding the microk8s user to the snapcraft pattern, or use snap_*? | 13:38 |
| ijohnson[m] | mardy for now just following snap_daemon makes sense | 13:40 |
| ijohnson[m] | When we need to add a 3rd user then we should do something different I think | 13:41 |
| pedronis | that sounds fine to me, just wanted to clarify the principle | 13:43 |
| futuretim_ | is spread _only_ available as a snap? | 14:15 |
| om26er | Hi! How can I make my python based snap to use python 3.9 ? | 14:15 |
| ijohnson[m] | futuretim_: either as a snap, or as a binary you download or build from source | 14:16 |
| futuretim_ | ijohnson[m]: of course from source :P | 14:16 |
| om26er | The software I am trying to update, recently added the Python 3.9 requirement, so now I need to figure that out | 14:16 |
| futuretim_ | om26er: there's a forum thread about something similar I believe, also hello :) | 14:18 |
| om26er | futuretim_ Hey Tim | 14:19 |
| om26er | futuretim_ I haven't found any useful thread regarding that. One option I could think of is to NOT use the python plugin and install my package using `override-build` stanza and also adding python3.9 to stage-packages | 14:20 |
| om26er | however I was wondering if there is a way to tell the Python plugin to use a different version of Python instead of the default that it picks from the relevant core snap | 14:21 |
| futuretim_ | om26er: it doesn't seem like it: https://forum.snapcraft.io/t/proposal-extensive-python-version-support-for-python-plugin/19140 | 14:23 |
| futuretim_ | That's a thread about a plan to do that? | 14:23 |
| mardy | it's "funny" how the HACKING.md document of snapcraft does not say how to actually build and run snapcraft :-) | 14:29 |
| futuretim_ | mardy: i've done it a little bit from source, it's not too bad | 14:38 |
| futuretim_ | I'm trying to run the spread smoke test and have gotten to this point: "Cannot allocate qemu:ubuntu-core-20-64: cannot launch qemu qemu:ubuntu-core-20-64: exec: "kvm": executable file not found in $PATH" | 14:40 |
| futuretim_ | i'm using the snap based spread, qemu-kvm is installed | 14:40 |
| futuretim_ | oh, and I just tried kvm directly and it works.. so it's a snap based problem? | 14:41 |
| ijohnson[m] | futuretim_: do you need to run uc20 spread tests specifically ? | 14:41 |
| pedronis | ironically the spread snap is not regularly updated and has known quirks/limitations | 14:42 |
| futuretim_ | ijohnson[m]: oh actually, not necessarily. Just "playing" at the moment. Want to familiarize myself with spread's capabilities. | 14:42 |
| futuretim_ | is there something about those that wouldn't work? | 14:43 |
| ijohnson[m] | futuretim_: for now I would recommend running non-uc20 spread tests, you need to tweak spread in confusing ways to be able to use uc20, since it requires uefi which is different from all the others systems which just use plain ol bios | 14:44 |
| futuretim_ | ijohnson[m]: ok, thanks for the note.. but that doesn't really explain my specific issue, does it? | 14:44 |
| ijohnson[m] | futuretim_: ah sorry you're right, yeah the spread snap runs in strict and so it doesn't have kvm inside the snap, usually the spread snap is just used to run tests in the cloud, for now I would recommend using the binary directly | 14:45 |
| ijohnson[m] | futuretim_: updating the spread snap to be more usable is on our (long) todo list | 14:45 |
| futuretim_ | ijohnson[m]: ok, can do. thanks! | 14:45 |
| mardy | I'm getting a "Cannot find snapcraft's data files." error when running a locally build copy of snapcraft (./setup.py install from within the LXC container) | 14:47 |
| ijohnson[m] | @mardy probably have better luck asking in #snapcraft | 14:51 |
| futuretim_ | mardy: check setup_dirs though | 14:52 |
| futuretim_ | I get access denied on this path from the snapd HACKING markdown: curl https://niemeyer.s3.amazonaws.com/spread-amd64.tar.gz | 14:55 |
| mardy | ijohnson[m]: ah, didn't know there was a specific channel | 14:59 |
| mardy | futuretim_: thanks, looking... | 14:59 |
| zyga-mbp | futuretim_ spread snap seems to be unmaintained | 15:10 |
| zyga-mbp | futuretim snap based spread cannot use some backends (kvm/lxd) | 15:10 |
| zyga-mbp | futuretim you are much better off building your own | 15:10 |
| * cachio lunch | 16:12 | |
| pedronis | ijohnson[m]: does https://github.com/snapcore/snapd/pull/10165 need more reviews? (I can't quite review it myself as I started it) | 17:19 |
| ijohnson[m] | pedronis no I don't think so | 17:44 |
| ijohnson[m] | It should be good to go | 17:44 |
| ijohnson[m] | I think I was just waiting for tests to be green | 17:44 |
| ijohnson[m] | pedronis: yeah I checked and the tests are all happy there, since I added the fix to the reboots variant, I haven't seen those tests fail once in CI out of maybe 3 runs (triggered by new commits I pushed) | 18:00 |
| * ijohnson[m] afk for a few hours, back in PM | 18:14 | |
| pedronis | ijohnson[m]: is this also unneeded https://github.com/snapcore/snapd/pull/10165/files#diff-62e70d55d61af70f84fe10b18afbdc094bc67bc9ee884f9f522b91e09335b1d7R20 ? | 18:15 |
| ijohnson[m] | pedronis: ah hmm probably but it would be good to do that in a followup | 18:16 |
| futuretim_ | anybody try RustPython in a snap as their Python runtime? :) | 18:37 |
| futuretim_ | what about making the Python a WASM WASI module and using that instead... that sounds appealing | 18:38 |
| cachio | ijohnson[m], I already updated the pr for the nested retry tool | 19:15 |
| cachio | thanks for the review | 19:15 |
| futuretim | I don't suppose there's a way to learn more about the Snap store outside of existing API docs? | 22:43 |
| futuretim | anybody interested and didn't already see the forum posts, hacking on an open source store implemtnation over at #freetocompute | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!