| mborzecki | morning | 06:38 |
|---|---|---|
| zyga | good morning | 07:21 |
| mborzecki | zyga: hey | 07:26 |
| zyga | :-) | 07:26 |
| zyga | any crazy purchases? | 07:26 |
| * zyga starts the day with reviews | 07:27 | |
| mborzecki | zyga: nope, not falling for the black friday bs with fake discounts around here | 07:35 |
| zyga | mborzecki: I got a real discount, I think | 07:35 |
| zyga | mborzecki: got a monitor at 2/3 the price (and I did check regular price as well as manufacturer recommended retail price0 | 07:36 |
| mborzecki | zyga: what display did you buy? | 07:36 |
| zyga | samsung space 27" 144Hz VA 2K panel | 07:36 |
| mborzecki | zyga: nice | 07:40 |
| pstolowski | morning | 08:01 |
| zyga | hey pstolowski | 08:04 |
| zyga | pstolowski: do you have that dock already? | 08:04 |
| zyga | mborzecki: https://github.com/snapcore/snapd/pull/7824#pullrequestreview-324890688 | 08:04 |
| mup | PR #7824: snap/squashfs, osutil: verify files/dirs can be accessed by mksquashfs when building a snap <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7824> | 08:04 |
| pstolowski | zyga: no, should arrive around Wed | 08:05 |
| mborzecki | zyga: thanks for the review | 08:08 |
| mborzecki | pstolowski: hey | 08:08 |
| zyga | Modeenv | 08:29 |
| zyga | why not ModeEnv | 08:29 |
| zyga | brb | 08:34 |
| sdhd-sascha | hi, good morning | 08:40 |
| * zyga turned up heating | 09:04 | |
| zyga | I have 15C in the office now | 09:04 |
| mborzecki | zyga: it's late atumn after all | 09:13 |
| zyga | and | 09:16 |
| zyga | the office has poor insulation :) | 09:17 |
| zyga | thinner walls, cold garage below | 09:17 |
| zyga | I would love to make it better one day, even if I have to insulate the celling downstairs | 09:17 |
| mborzecki | zyga: heh walk() does not follow symlinks, filepath.Walk("/snap/core/current"..), works differently that filepath.Walk("/snap/core/current/") | 09:18 |
| zyga | yeah :) | 09:18 |
| zyga | but it's just the outer initial symlink that matters to us | 09:18 |
| zyga | we don't want to follow symlinks inside, right? | 09:18 |
| tomwardill | hi, store team here. Store is currently down, it's being looked at. | 09:20 |
| * zyga hugs tomwardill | 09:20 | |
| zyga | thank you and good luck | 09:20 |
| * tomwardill is mostly drinking coffee and watching people far more competent than I am, but I'll pass the sentiments on :) | 09:20 | |
| mborzecki | zyga: anyways, refactored to use walk now, before i readdin'ing manually in order to faccessat, since that doesn't work bc of osx, might as well just use walk | 09:21 |
| zyga | mborzecki: macos has some innovation in the case of fstat-like functions | 09:21 |
| zyga | mborzecki: as well as in the case of "readdir" like functions | 09:22 |
| zyga | so the old syscalls are gone now | 09:22 |
| zyga | mborzecki: fstat has been replaced by something that is like statx but x10 more complex with lots of extra features and things one can ask about | 09:22 |
| zyga | mborzecki: and readdir is more like "search" now | 09:22 |
| Chipaca | tomwardill: from here it looked like a lot more than just the store was down :) | 09:22 |
| zyga | mborzecki: I think there's still the old readdir but it's deprecated and returns a subset of data now | 09:22 |
| tomwardill | Chipaca: PS4.5 is out | 09:23 |
| zyga | oouch! | 09:23 |
| Chipaca | tomwardill: is the internal irc on that? | 09:23 |
| tomwardill | yes | 09:23 |
| Chipaca | ah, nice | 09:23 |
| tomwardill | or at least, behind the same switch | 09:23 |
| Chipaca | ah | 09:23 |
| tomwardill | irc has just come back for me btw | 09:23 |
| zyga | will PS5 run on a xmas-lot of playstation 5 boxes? :) | 09:23 |
| Chipaca | i thought it ran on a 486 unde elmo's desk :-p | 09:23 |
| zyga | now powering AI/ML workloads ;) | 09:23 |
| zyga | haha | 09:24 |
| mborzecki | updated #7824 | 09:28 |
| mup | PR #7824: snap/squashfs, osutil: verify files/dirs can be accessed by mksquashfs when building a snap <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7824> | 09:28 |
| Chipaca | mborzecki: why not do those checks from snap/pack's loadAndValidate? | 09:31 |
| Chipaca | mborzecki: as part of ValidateContainer for ex | 09:32 |
| Chipaca | mborzecki: that way you still get the error in 'snap pack', but snapcraft gets to warn about it early | 09:33 |
| mborzecki | Chipaca: because it may be intentional to have the path set to 0000 or otherwise unreadable by the user | 09:33 |
| mborzecki | Chipaca: iirc that code checks that snap own meta and files are accessible | 09:33 |
| mborzecki | s/accessible/present/ | 09:33 |
| zyga | mborzecki: do you want to check the return value of Walk itself? | 09:33 |
| mborzecki | zyga: heh, clearly need another coffee | 09:35 |
| mborzecki | Chipaca: what i mean is that, current uid being unable to pack the snap doesn't mean it's invalid | 09:37 |
| zyga | mborzecki: one more question https://github.com/snapcore/snapd/pull/7824/files#r352494084 | 09:37 |
| mup | PR #7824: snap/squashfs, osutil: verify files/dirs can be accessed by mksquashfs when building a snap <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7824> | 09:37 |
| Chipaca | mborzecki: right | 09:37 |
| zyga | Chipaca: that's true but it also means the current uid won't be able to pack it :) | 09:37 |
| zyga | and that's worth checking | 09:37 |
| zyga | mborzecki: added two comments and resuming other reviews | 09:38 |
| zyga | brb | 09:38 |
| mborzecki | zyga: i'm all for using a smarted syscall than access, but the only alternative is trying to open that location, checking permission bits is too simple | 09:41 |
| zyga | mborzecki: but access is doing just permission check | 09:41 |
| zyga | it doesn't do anything else, does it? | 09:42 |
| zyga | I guess we could just open and try, that's portable and reliable | 09:42 |
| mborzecki | heh, so maybe we should just open | 09:42 |
| abeato | morning! we are noticing that some times it takes a lot of time to get a snap installed due to snapd wanting random numbers and the rng not being initialized yet | 09:46 |
| abeato | which is the rationale for snapd needing random numbers when installing a snap¿ | 09:46 |
| abeato | ? | 09:46 |
| zyga | abeato: good morning, is this on a vm? | 09:46 |
| zyga | abeato: that's unclear, I cannot think of any | 09:46 |
| abeato | no, on real HW | 09:46 |
| zyga | abeato: we generate some random numbers for snap cookies | 09:47 |
| zyga | perhaps that's that | 09:47 |
| abeato | on the Jetson Xavier, and on other devices on other prokects | 09:47 |
| zyga | is there a hardware random number generator on the xavier? | 09:48 |
| zyga | I wonder if it's just snaps that are affected | 09:48 |
| zyga | or generally software waiting and waiting | 09:48 |
| abeato | there is a trng, yes, but I think that due to a kernel bug the rng gets ~5 minutes to get initialized | 09:49 |
| abeato | so, on one hand this is a kernel problem, but on the other hand I do not think it makes much sense that snapd has to block on urandom to be initialized | 09:50 |
| abeato | the main issue is that we are seeing this on many deviced, not just one | 09:50 |
| zyga | abeato: right, I understand that | 09:50 |
| zyga | I think we investigated that once before | 09:50 |
| zyga | but it's lots of other parts of the stack that want entrop | 09:51 |
| zyga | *entropy | 09:51 |
| zyga | and us being super careful won't fix the general "it's stuck" feel | 09:51 |
| zyga | I think systemd is in the same boat | 09:51 |
| zyga | we don't depend on randomness in an unreasonable way, I think, we could do another analysis to check if anything new was added by accident | 09:51 |
| abeato | hm, well, systemd starts, not sure if there is much delay there | 09:52 |
| abeato | for FDE you would get things blocked too, sure | 09:52 |
| tomwardill | store update: most of the store should be back, SSO is still down | 10:03 |
| sdhd-sascha | What is the best way to strace/ltrace or debug an application inside a snap? Sway starts, Xwayland and Xwayland runs xkbcomp... And/Or does a wayland snap need X support ? | 10:27 |
| zyga | sdhd-sascha: there's snap run --strace | 10:29 |
| zyga | but it's sometimes a little broken | 10:29 |
| zyga | and AFAIK we also have snap run --gdb | 10:29 |
| zyga | as for Xwayland -- I don't know | 10:30 |
| sdhd-sascha | zyga: yes, i saw a file in the source with the name strace. But didn't have the time to inspect ... So it just ask | 10:30 |
| sdhd-sascha | Well, sway depends on dmenu for launching application. It's X11. | 10:31 |
| sdhd-sascha | Then the most GDK/GTK applications are not compiled with wayland or prefer X11. | 10:31 |
| sdhd-sascha | I read on a debian changelog, that there are problems with the clipboard between X11 and wayland. So they prefer to start the application as X, if available. | 10:32 |
| sdhd-sascha | Now i wonder, what the usecase of wayland inside a snap is. If kiosk with custom application, then no X11 is needed. But if it's a full desktop, then we need Xwayland support. | 10:33 |
| sdhd-sascha | Weston is very nice here. It does not depend on external Xwayland but has similar problems with xkbcomp currently | 10:33 |
| zyga | I'm sorry I just don't know enough about the desktop stack to give useful advice | 10:35 |
| zyga | https://github.com/snapcore/snapd/pull/7129 needs a second review | 10:36 |
| sdhd-sascha | zyga: it's ok. my opinion is, i will make it run. After that i need help to implement some plugs for common GUI-Frameworks | 10:36 |
| zyga | it's very old by now | 10:36 |
| mup | PR #7129: userd: allow setting default-url-scheme-handler <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129> | 10:36 |
| zyga | more reviews :) | 10:49 |
| zyga | r-e-v-i-e-w-s :) | 10:56 |
| mborzecki | zyga: can you take a look at https://github.com/snapcore/snapd/pull/7743 ? | 11:10 |
| mup | PR #7743: snap-bootstrap: force partition table operations <Simple 😃> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7743> | 11:10 |
| zyga | sure, just a moment | 11:10 |
| zyga | brb | 11:10 |
| zyga | reading a longer test | 11:19 |
| zyga | I should take a swap day | 11:19 |
| zyga | need to burn it | 11:19 |
| zyga | before xmas | 11:19 |
| zyga | mborzecki: looking now | 11:40 |
| zyga | mborzecki: hmm | 11:46 |
| zyga | mborzecki: somewhat worried | 11:46 |
| zyga | mborzecki: so the thing that we're operating on is mounted, right? | 11:46 |
| zyga | because we've booted | 11:46 |
| zyga | and now we're changing partitions b | 11:46 |
| zyga | are all partitions that we are changing unmounted? | 11:46 |
| mborzecki | zyga: afaiu this ties into the uc20 setup process, i'm slightly concerned about it but i suppose it has been thought through | 11:49 |
| zyga | I'm concerned and not equally optimistic | 11:49 |
| mborzecki | zyga: heh, did you look through the spec? | 11:50 |
| zyga | rapidly | 11:50 |
| zyga | I should read it again | 11:50 |
| zyga | re | 12:30 |
| zyga | hey cmatsuoka | 12:30 |
| cmatsuoka | zyga: hi | 12:31 |
| cmatsuoka | zyga: I'm also reading sfdisk.c | 12:31 |
| cmatsuoka | zyga: it seems that we could use --no-reread instead of --force, and read the PT afterwards (which we already do) | 12:33 |
| cmatsuoka | zyga: but if we could trigger the partition device node creation in a different way, then this second PT update wouldn't be necessary anymore | 12:34 |
| cmatsuoka | zyga: I'm completely for understanding exactly what's happening there because I feel things are a bit out of control there | 12:35 |
| zyga | we are in agreement | 12:36 |
| cmatsuoka | so one unknown here is: why partx is necessary to trigger node creation for newly created partitions? sfdisk itself and blockdev --rereadpt won't do that | 12:37 |
| zyga | cmatsuoka: I'm checking what --force does in practice | 12:41 |
| zyga | one thing is is doing is fdisk_device_is_used check gets ignored | 12:41 |
| zyga | let's see what that does | 12:41 |
| cmatsuoka | zyga: yeah, I'm exactly there now | 12:42 |
| zyga | hmm | 12:43 |
| zyga | one ioctl :) | 12:43 |
| zyga | let's see what that is | 12:43 |
| cmatsuoka | zyga: it's a bit disturbing that all those utilities seem to use a certain amount of guesswork ("it seems that the kernel...", "I think this...", "I don't know why, but...") | 12:43 |
| zyga | yeah | 12:43 |
| zyga | linux plumbing layer is full of traps | 12:44 |
| zyga | it's not nice in many ways | 12:44 |
| zyga | (not that others are) | 12:44 |
| zyga | heh | 12:44 |
| zyga | manual pages are silent | 12:44 |
| zyga | looking at the kernel | 12:44 |
| zyga | that's the only relief | 12:44 |
| zyga | at the end of the day | 12:44 |
| zyga | you just read and know | 12:44 |
| zyga | I'm curious to know what is ABBA deadlock now | 12:47 |
| cmatsuoka | humm, I'll verify this, but I'm suspecting the node creation trigger happens with BLKPG but not with BLKRRPART | 12:47 |
| zyga | in initramfs what is mounted on /dev? | 12:47 |
| cmatsuoka | devtmpfs I guess? not sure | 12:48 |
| zyga | do you know what populates it? | 12:48 |
| zyga | is it kernel itself or kernel + udev or udev from kernel events? | 12:49 |
| cmatsuoka | I don't know. I can check there but I'm not in bootable state right now | 12:49 |
| cmatsuoka | But I think we must see that in the new initramfs xnox just built | 12:50 |
| cmatsuoka | which may be different compared to the old ones | 12:51 |
| cmatsuoka | xnox: you there? | 12:51 |
| zyga | reading the kernel | 12:54 |
| zyga | I start to see what happens | 12:54 |
| cmatsuoka | zyga: the ABBA deadlock happens when two threads get two locks and then they try to get each other's locks | 12:55 |
| cmatsuoka | if I remember correctly | 12:55 |
| zyga | ah | 12:55 |
| zyga | I see | 12:55 |
| zyga | I thought it's a weird abba reference | 12:55 |
| zyga | it's just A B B A, as in thread names | 12:55 |
| zyga | :D | 12:55 |
| cmatsuoka | ah yes, threads A and B :D | 12:56 |
| cmatsuoka | zyga: hey wait wait, you said --force will skip the BLKRRPART ioctl? | 13:00 |
| cmatsuoka | (and then the partition table won't be updated anyway?) | 13:01 |
| cmatsuoka | hm, not exactly, but it seems to me that the ioctl() call is always failing and --force is just masking that | 13:04 |
| cmatsuoka | that would explain everything except why the ioctl call fails | 13:05 |
| zyga | yes | 13:05 |
| zyga | force is igoring that | 13:05 |
| zyga | the ioctl always runs | 13:05 |
| zyga | I'm reading the kernel side to see when it fails | 13:06 |
| zyga | (I also have a cold, sorry for the frequent interrupts when I'm away) | 13:06 |
| cmatsuoka | so I think it's failing because seed is mounted, and --force just makes it ignore the fact that the ioctl failed | 13:06 |
| cmatsuoka | so --no-reread is more appropriate here, it seems | 13:07 |
| zyga | what is the error we are getting in sfdisk again | 13:07 |
| zyga | oh boy | 13:08 |
| cmatsuoka | zyga: this one: https://github.com/karelzak/util-linux/blob/master/disk-utils/sfdisk.c#L1696 | 13:08 |
| zyga | it's only logged | 13:08 |
| zyga | yeah but are we getting EINVAL, E...what? | 13:08 |
| cmatsuoka | zyga: I don't know, I'll have to run it again to be sure | 13:09 |
| zyga | there's a way to get more output | 13:09 |
| zyga | there's a DBG macro | 13:09 |
| zyga | just need to figure out how to enable it | 13:09 |
| mborzecki | zyga: LIBFDISK_DEBUG=all ? | 13:13 |
| zyga | thank you! | 13:13 |
| cmatsuoka | ok, building an instrumented image | 13:17 |
| zyga | cmatsuoka: this is an interesting page https://unix.stackexchange.com/questions/141476/forced-reread-of-partition-table-difference-between-blkrrpart-and-blkpg-ioctl | 13:18 |
| cmatsuoka | zyga: we can check this in the kernel, but maybe BLKRRPART fails when partitions are mounted and BLKPG doesn't? | 13:19 |
| zyga | yeah | 13:20 |
| zyga | I think so | 13:20 |
| cmatsuoka | so partx and possibly partprobe would work while sfdisk and blockdev fail | 13:20 |
| cmatsuoka | that would explain everything | 13:20 |
| cmatsuoka | zyga: https://pasteboard.co/IJonVQV.png | 13:39 |
| zyga | thanks! | 13:39 |
| zyga | EBUSY | 13:40 |
| cmatsuoka | yep | 13:40 |
| zyga | just three places where that is returned | 13:40 |
| zyga | looking | 13:40 |
| zyga | or just a few | 13:41 |
| zyga | cmatsuoka: when we partition the disk, what's the state of the existing partitions | 13:56 |
| zyga | cmatsuoka: is the disk largely unpartitioned | 13:57 |
| zyga | cmatsuoka: and we append? | 13:57 |
| zyga | I read the code and I think the change is "safe" | 13:57 |
| cmatsuoka | zyga: we have the system-seed partition there, which is also our boot partition | 13:57 |
| zyga | in this sense | 13:57 |
| zyga | brb, see you at the standup | 13:57 |
| sdhd-sascha | hey, sorry for this "noob" question. But where is the XDG_RUNTIME_DIR set on login ? I grep'ed the whole /etc. Took a look at /etc/pam.d/. | 14:07 |
| sdhd-sascha | I wonder why it was set on "ssh" and "ttyX", but not on "sudo su" | 14:07 |
| Chipaca | cmatsuoka: https://www.youtube.com/watch?v=ytWz0qVvBZ0 | 14:08 |
| sdhd-sascha | oh, i think it's inside systemd | 14:09 |
| zyga | sdhd-sascha: it's complex | 14:12 |
| zyga | sdhd-sascha: it's set by pam AFAIK but I don't know enough to tell you and point to a file where this happens | 14:12 |
| cmatsuoka | Chipaca: :D | 14:12 |
| sdhd-sascha | zyga: currently i only need to trigger the environment, so i can call "weston-launch" as root | 14:13 |
| sdhd-sascha | i could also set it manually.. | 14:13 |
| sdhd-sascha | zyga: maybe i should look, howto increase the logging level of systemd ;-) | 14:15 |
| mborzecki | zyga: cmatsuoka: imo that delay is needed because partitions would show up/go away asynchronously | 14:23 |
| zyga | yeah | 14:24 |
| zyga | it's an event | 14:24 |
| zyga | we could instead look for them on disk | 14:24 |
| zyga | that would be less racy | 14:24 |
| zyga | if we know we expect /dev/xxx2 | 14:24 |
| mborzecki | zyga: cmatsuoka: and then udev is another async bit that should get some extra delay if you want to use /dev/disk/by-{name,label,uuid}.. | 14:24 |
| zyga | Chipaca: https://www.youtube.com/watch?v=dHoCeqlU2g8 (though it's mostly in Polish) | 14:25 |
| zyga | but it's fun ;) | 14:25 |
| cmatsuoka | mborzecki, zyga: yeah, I remember this node creation race that crashed the kernel back in the spike days | 14:25 |
| zyga | Chipaca: skip to 1;30 | 14:26 |
| === ricab is now known as ricab|lunch | ||
| zyga | cmatsuoka: https://github.com/snapcore/snapd/pull/7743#issuecomment-560420462 | 14:31 |
| mup | PR #7743: snap-bootstrap: force partition table operations <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7743> | 14:31 |
| cmatsuoka | Chipaca: bah, no Diggy Diggy Hole t-shirts for me | 14:31 |
| cmatsuoka | Chipaca: hmm, maybe the 12-14 years size could fit? | 14:31 |
| Chipaca | cmatsuoka: the t-shirt link is a 404 from here so count yourself lucky (?) | 14:33 |
| cmatsuoka | Chipaca: if you go to the store main page and search from there you'll find a kids size t-shirt | 14:34 |
| Chipaca | cmatsuoka: i'm so sorry | 14:34 |
| * cmatsuoka sings Down and down into the deep, who knows what we'll find beneath? | 14:34 | |
| * Chipaca updates cmatsuoka's race card to 'dwarf' | 14:36 | |
| cmatsuoka | actually there's one in the video that looks a lot like our friend zygmunt | 14:37 |
| zyga | cmatsuoka: is my comment sensible? | 14:42 |
| zyga | cmatsuoka: note, alternatively --no-reread is okay as well, as it has the equivalent effect | 14:43 |
| mborzecki | off to pick up the kids | 14:43 |
| cmatsuoka | zyga: I think --no-reread would be a more conservative approach because it has a well-defined meaning and maybe what --force does could change in future versions of the utility. In practice, now, both would have the same effect | 14:45 |
| zyga | I agree | 14:45 |
| cmatsuoka | Ok, I'll prepare a patch with --no-reread and update the comments | 14:45 |
| zyga | Thanks! | 14:46 |
| cmatsuoka | thank you zyga for digging into this | 14:46 |
| zyga | mborzecki: thanks for looking at --explain, | 14:47 |
| zyga | mborzecki: the marker, did you mean to use some kind prefix for each line | 14:48 |
| zyga | mborzecki: or something else? | 14:48 |
| cmatsuoka | Chipaca: https://www.youtube.com/watch?v=34CZjsEI1yU | 14:48 |
| === alan_g_ is now known as alan_g | ||
| * zyga switches gears to https://github.com/snapcore/snapd/pull/7815 | 14:53 | |
| mup | PR #7815: tests: reduce the complexity of the test-snapd-sh snap <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7815> | 14:53 |
| zyga | cachio: I pushed a small tweak there | 15:04 |
| cachio | zyga, thanks | 15:05 |
| cachio | I'll take a look to that PR | 15:05 |
| sdhd-sascha | Chipaca: :-D | 15:09 |
| * cachio lunch | 15:10 | |
| Chipaca | cmatsuoka: mucho bettero | 15:10 |
| cachio | pstolowski, the hotplug test is failing here https://paste.ubuntu.com/p/VbRsMH3Sjx/ | 15:12 |
| cachio | pstolowski, not sure it is related to any change | 15:12 |
| cachio | done recently | 15:13 |
| cachio | but if fails twice and I can reproduce it | 15:13 |
| * ijohnson is all caught up on emails/backlog | 15:14 | |
| pstolowski | cachio: weird, we haven't touched anything there. full log? | 15:14 |
| ijohnson | zyga: shall I review https://github.com/snapcore/snapd/pull/7825 ? looks like it's ready for review? | 15:14 |
| mup | PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825> | 15:15 |
| cachio | pstolowski, https://paste.ubuntu.com/p/fwm2MhW6bs/ | 15:16 |
| cachio | pstolowski, the log is huge | 15:16 |
| cachio | pstolowski, it appears /dev/ttyUSB0 rwk, | 15:17 |
| zyga | dinner is coming up, everyone's home now | 15:17 |
| cachio | and we are trying to match "/dev/ttyUSB0 rw," | 15:17 |
| zyga | cachio: I need to read only a small chunk of the diff before finishing my review but it's the most important one | 15:17 |
| zyga | I'll finish today for sure | 15:17 |
| cachio | zyga, thanks | 15:17 |
| pstolowski | cachio: aah, maybe we landed "+k" change, that would explain it | 15:18 |
| pstolowski | cachio: we planned to change serial port permissions | 15:18 |
| cachio | pstolowski, ahh | 15:21 |
| cachio | so we should update the test in that case right? | 15:21 |
| cachio | pstolowski, I can do it after lunch | 15:22 |
| cachio | pstolowski, does it make sense? | 15:22 |
| * cachio lunch again | 15:26 | |
| === ricab|lunch is now known as ricab | ||
| jdstrand | ijohnson: hey, you asked about '... (i.e. seccomp) and non-root owned "/"' | 15:34 |
| ijohnson | good morning jdstrand :-) | 15:34 |
| ijohnson | yes I did ask about that | 15:34 |
| ijohnson | do you want me to re-ask? | 15:35 |
| jdstrand | ijohnson: I see the question. you asked if I had time to chat. I didn't then but can now. what is up?> | 15:35 |
| ijohnson | ah right sorry I have forgotten what I sent | 15:35 |
| ijohnson | let me find the forum page for the full context | 15:36 |
| ijohnson | so here someone is trying to use snaps on azure pipelines: https://forum.snapcraft.io/t/permissions-problem-using-snapcraft-in-azure-pipelines/13258 | 15:36 |
| jdstrand | ijohnson: ok, I am going through irc backscroll first and not caaught up on email yet | 15:36 |
| ijohnson | jdstrand: what's weird is that on azure pipelines, "/" is not root-owned, and so snap-confine refuses to run | 15:36 |
| ijohnson | jdstrand: and looking through git history it seems that the reason snap-confine does the check for "/" and all elements of the path down to where we have seccomp compiled programs being root owned is to protect against someone putting bad bpf programs there and doing an escalation attack | 15:38 |
| ijohnson | jdstrand: so my question is if we can do anything about this case to loosen that requirement or enable some kind of flag to allow running snaps on azure pipelines like this | 15:39 |
| jdstrand | ijohnson: I've read the topic and you are right in why we are doing that. we are doing that for security reasons. I can't think of a legitimate reason why / is not owned by root. | 15:39 |
| ijohnson | yeah it's weird, but it does seem like a deliberate action, it doesn't seem like something someone would do on accident | 15:40 |
| jdstrand | ijohnson: I would like to understand why that is a legitimate use case. usually, there is a coding error somewhere in a maintainer script type thing that accidentally chowns / | 15:40 |
| jdstrand | ijohnson: chown vsts $TPYO/ | 15:41 |
| jdstrand | ijohnson: there have been USNs to fix CVEs in deb packaging for this type of thing | 15:41 |
| ijohnson | ah yes I could see that happening | 15:41 |
| ijohnson | let me see if I can find a place we could file an issue to get more context from azure | 15:42 |
| zyga | jdstrand: it would be so funny if that was the case | 15:42 |
| zyga | jdstrand: "Q: can you fix your software not to check / owner" | 15:43 |
| zyga | jdstrand: "A: can you apply this patch not to chown / from maintainer script" | 15:43 |
| zyga | ;) | 15:43 |
| pstolowski | cachio: yes, thank you | 15:43 |
| jdstrand | zyga: yeah. well, ufw I think was the first thing to do this checking in Ubuntu anyway, and it found a CVE in hplip :) | 15:43 |
| zyga | jdstrand: haha | 15:44 |
| zyga | jdstrand: so it *is* good that we ask for root password to install that printer ;) | 15:44 |
| pstolowski | cachio: i've just verified, we now have "rwk" on serial port | 15:44 |
| jdstrand | zyga: people said: "jdstrand> your check is too strict. please fix". I was like, uhm, why does hplip own /? You realize it can now change anything underneath it, right? | 15:45 |
| mborzecki | zyga: i think something like `<< snap explain start >>\n`, `<< snap explain end >>\n` would be enough | 15:45 |
| jdstrand | zyga: heh | 15:45 |
| zyga | mborzecki: that was not part of the initial design but I'll play with it | 15:45 |
| zyga | it's an experiment after all :) | 15:45 |
| mborzecki | zyga: iirc kernel has some ------[ cut here ] ------------- markers for backtraces | 15:45 |
| zyga | mborzecki: ah, I se | 15:45 |
| zyga | it would be just printed twice | 15:45 |
| zyga | that's nice | 15:45 |
| zyga | I'm semi-afk | 15:46 |
| mborzecki | zyga: otherwise my feeling is that the output of the actual app and the one from explain could be easily confused | 15:46 |
| zyga | Lucy is roaming around the office | 15:46 |
| ijohnson | jdstrand: zyga: well I tried looking and without an azure account the best they can do to talk to us is to ask on the stack exchange :-/ | 15:46 |
| jdstrand | ijohnson: https://forum.snapcraft.io/t/permissions-problem-using-snapcraft-in-azure-pipelines/13258/13 | 15:56 |
| jdstrand | ijohnson: I suspect one of the people asking for the change can use that when filing a bug with their azure account | 15:58 |
| ijohnson | jdstrand: ack yes that sounds fine, I did also ask on their stack exchange about it fwiw | 15:59 |
| jdstrand | cool, thanks | 16:00 |
| ijohnson | thanks jdstrand! | 16:00 |
| * Chipaca afk | 16:36 | |
| jdstrand | ogra: thanks for the response re usb drive. I don't mind an sd card and am happy to do that, but it feels more correct to be able to boot off the usb directly. if that requires a blob from someone I don't know though, I prefer the approach you outlined :) | 16:40 |
| zyga | re | 17:32 |
| cachio | git push | 17:33 |
| zyga | git-clippy: where do you want to push today | 17:34 |
| pstolowski | :) | 17:35 |
| mup | PR snapd#7827 opened: tests: apply change on permissions to serial port on hotplug test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7827> | 17:36 |
| pstolowski | +1 | 17:37 |
| cachio | thanks | 17:37 |
| pstolowski | zyga: ^ can you look at it as well, trivial test update | 17:38 |
| cachio | I am going to the dentist now | 17:38 |
| zyga | yeah | 17:38 |
| cachio | I'll be back in 40 minutes | 17:38 |
| sergiusens | jdstrand: hey,maybe consider escaping the _ on https://forum.snapcraft.io/t/mpris-name-for-media-player-snap/14371/7 | 17:38 |
| cachio | pstolowski, I'll try to merge it today | 17:38 |
| pstolowski | ijohnson was faster :) | 17:38 |
| ijohnson | :-) | 17:38 |
| cachio | ijohnson, pstolowski thanks guys | 17:38 |
| zyga | pstolowski: what happened that the permissions changed? | 17:39 |
| ijohnson | zyga: folks want to lock the serial-port, there are various forum topics about this | 17:39 |
| pstolowski | zyga: apparmor (kernel?) change at some point, jdstrand updated serial-port to grant locking permission as it was missing know, was implicit before | 17:39 |
| * ijohnson goes to look | 17:40 | |
| zyga | aha | 17:40 |
| pstolowski | s/know/now/ | 17:40 |
| zyga | kernel side changed or our side changed? | 17:40 |
| zyga | the patch looks good , I'm just wondering why it wasn't checked earlier and caused something to fail | 17:40 |
| pstolowski | zyga: afair it was an apparmor or kernel bug | 17:41 |
| pstolowski | zyga: but not ours | 17:41 |
| zyga | pstolowski: but do you know if "our" side has changed? | 17:41 |
| zyga | because it is clearly measuring snapd files | 17:41 |
| zyga | so it must have come from snapd patch | 17:41 |
| zyga | so ... why didn't this change happen in sync then? | 17:41 |
| pstolowski | zyga: yes, we added +k to serial.port.go | 17:41 |
| ijohnson | see https://forum.snapcraft.io/t/hotplug-doesnt-allow-access-like-a-gadget-slot-does/14090 | 17:41 |
| zyga | was the test not executed? | 17:42 |
| pstolowski | zyga: because this spread test is run only on demand (nested execution) | 17:42 |
| zyga | ah | 17:42 |
| zyga | that was the thing I was after | 17:42 |
| ijohnson | zyga: the PR jdstrand submitted changing the policy is https://github.com/snapcore/snapd/pull/7779 | 17:42 |
| mup | PR #7779: interfaces: misc updates for u2f-devices, browser-support, hardware-observe, et al <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7779> | 17:42 |
| zyga | approved | 17:42 |
| zyga | thanks! | 17:42 |
| ijohnson | hey zyga, I'm reviewing 7825, and am I right in thinking we have a race condition between when we unlock the lock in genericRefreshCheck() and when we check `if PIDs := knownPids[app.SecurityTag()]; len(PIDs) > 0 {` ? | 17:44 |
| * zyga looks | 17:44 | |
| ijohnson | i.e. a snap process could launch in between those two things and knownPids would miss it | 17:44 |
| ijohnson | err s/miss/not contain/ | 17:44 |
| zyga | https://github.com/snapcore/snapd/pull/7825/files#diff-6eeb1fdef37cbd9f8f731642102858e1R59 | 17:46 |
| mup | PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825> | 17:46 |
| zyga | if I understand your question correctly the answer is "yes" and also "but that's by design" | 17:47 |
| mup | PR snapcraft#2823 closed: xattrs: switch to python's os package for reading/writing xattrs <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2823> | 17:47 |
| zyga | we don't want to have precise information about which pid is or is not in that group | 17:47 |
| zyga | it's not that interesting really | 17:47 |
| zyga | we're only interested in the fact that a given security tag had a non-empty list | 17:47 |
| ijohnson | zyga: right, I understand we don't really care about individual pids, we just want to know if the set of pids is empty or not. what I'm concerned about is if we unlock that lock after computing the set, a new snap process could launch while we are doing other things in that genericRefreshCheck() function that we wouldn't have allowed to launch if we held the lock longer | 17:49 |
| ijohnson | perhaps I'm being confused about which lock is being held there | 17:49 |
| zyga | yes, that's entirely possible and correct | 17:50 |
| zyga | it's unprotected at this time | 17:50 |
| ijohnson | but don't we not want that to happen? | 17:50 |
| zyga | there's going to be a new lock that is not a part of this PR | 17:50 |
| zyga | it will prevent that from happening | 17:50 |
| zyga | but it's not the current lock | 17:51 |
| zyga | where the "current" lock can only be held very very briefly | 17:51 |
| zyga | the new inhibit lock will actively stall startup and can be held during long operations (e.g. snap refresh downloads) | 17:51 |
| ijohnson | okay, if this is a known limitation we plan to resolve later and is effectively not worse than the current behavior then that's fine | 17:51 |
| zyga | that's correct, the current behavior is identically weak | 17:51 |
| zyga | it's making a point-in-time decision | 17:51 |
| ijohnson | it just seemed to me like we are releasing the lock sooner so we are introducing more race conditions | 17:51 |
| zyga | but before unlinking | 17:52 |
| zyga | so it's effectively still racy | 17:52 |
| ijohnson | got it, thanks for clarifying | 17:52 |
| ijohnson | and for working on all this, it _feels_ really close this time :-) | 17:52 |
| zyga | that's why I included that comment, it's a specific guarantee that we are providing only | 17:52 |
| zyga | ha, it's still somewhat distant but definitely better than before | 17:52 |
| zyga | the new inhibit lock is in another PR | 17:52 |
| zyga | but I need to rebase it on top of this thing as it's still using one of the earlier iterations | 17:53 |
| pstolowski | eod, cu | 17:53 |
| ijohnson | zyga: ack sounds good | 17:53 |
| * zyga needs to reboot | 18:02 | |
| === ijohnson is now known as ijohnson|lunch | ||
| * zyga-laptop EODs | 18:20 | |
| zyga-laptop | degville hey | 18:40 |
| zyga-laptop | post EOD question | 18:40 |
| zyga-laptop | do you happen to know what happened to ubuntu core downloads? | 18:40 |
| zyga-laptop | https://ubuntu.com/download/raspberry-pi has just server images | 18:40 |
| zyga-laptop | I found https://ubuntu.com/download/raspberry-pi-2-3-core but it's not linked from the download page | 18:42 |
| degville | zyga-laptop: hello! no, I don't know what's happened there. | 18:42 |
| zyga-laptop | it seems we are advertising classic | 18:42 |
| zyga-laptop | and core is on a distinct page that is in a void somewhere | 18:42 |
| zyga-laptop | I'm good for now but I just wanted to raise this | 18:43 |
| zyga-laptop | I'll make a video about how to install ubuntu core on a pi | 18:43 |
| zyga-laptop | and the first step is ... harder than I expected | 18:43 |
| degville | mmm... yeah, we're doing a poor comms job. Not sure why, or the motivation behind it. | 18:44 |
| degville | The compute docs are Core focused. | 18:44 |
| degville | https://ubuntu.com/download/raspberry-pi-compute-module-3 | 18:44 |
| zyga-laptop | oh well | 18:44 |
| zyga-laptop | I'll try to include this in the video | 18:45 |
| zyga-laptop | doing a quick note/screenplay thing now | 18:45 |
| zyga-laptop | it's pretty weird | 18:46 |
| zyga-laptop | if you go to ubuntu.com/download/iot | 18:46 |
| zyga-laptop | there's a big green install button | 18:46 |
| zyga-laptop | for pi 2 3 or 4 | 18:46 |
| zyga-laptop | but that's the classic page | 18:46 |
| degville | zyga-laptop: yeah, totally agree. | 18:46 |
| zyga-laptop | if you scroll below | 18:46 |
| degville | Just tried the same. | 18:46 |
| zyga-laptop | there's install ubuntu core | 18:46 |
| zyga-laptop | but it's a separate set of platforms | 18:46 |
| zyga-laptop | I guess I "get it" but it is messy | 18:46 |
| degville | zyga-laptop: my guess is not wanting to confuse the majority who may be looking for the Ubuntu-equivalent to Raspbian. But Core images are totally lost along the way. | 18:48 |
| zyga-laptop | yeah | 18:48 |
| zyga-laptop | I have the same feeling about both | 18:48 |
| zyga-laptop | I think we need more of a ... | 18:48 |
| zyga-laptop | https://www.opensuse.org | 18:49 |
| zyga-laptop | like chooser | 18:49 |
| zyga-laptop | it's a really clean page | 18:49 |
| degville | yes, you're right. | 18:49 |
| zyga-laptop | ijohnson|lunch thank you | 19:35 |
| === ijohnson|lunch is now known as ijohnson | ||
| zyga-laptop | I'll iterate tomorrow though, trying to record something tonight | 19:35 |
| ijohnson | k, np | 19:35 |
| ijohnson | good work on the branch! | 19:35 |
| === epod is now known as luk3yx | ||
| === mwhudson_ is now known as mwhudson | ||
| === arnatious_ is now known as arnatious | ||
| === wieczorek1990_ is now known as wieczorek1990 | ||
| === joedborg_ is now known as joedborg | ||
| === boxrick_ is now known as boxrick | ||
| === lfaraone_ is now known as lfaraone | ||
| === Trevinho_ is now known as Trevinho | ||
| === benoitc_ is now known as benoitc | ||
| === jwheare_ is now known as jwheare | ||
| mup | PR snapd#7828 opened: tests: demand silence from check_journalctl_log <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7828> | 21:36 |
| mup | PR snapd#7829 opened: tests: fix the channels checks done on nested tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7829> | 23:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
