[01:57] PR snapd#11652 closed: tests: update snapd testing tools [06:08] morning [06:32] mborzecki: hi! Historical question: has there ever been a time when snap-confine was running under some other user than root (I mean, before we started using sc_set_effective_identity())? [06:34] I'm asking because we are *sometimes* calling chown() on newly created directories, which seems weird [06:35] like for example you did here: 73e89cf8cae423bca52df128e2f8d3508068f55c [06:35] wasn't snap-confine running as root back then? [06:38] mardy: iirc that was done as part of suse review, the problem was that all of s-c would run as root as it's a setuid binary, so they requested to limit as-root operations only to what is really necessary [06:39] hence the code flips between uid/gid a number of times [06:48] mborzecki: yes, that makes sense. I'm just wondering why we added chown after mkdir, if the mkdirs already are done as the root user [06:48] mardy: whcih place? [06:50] mborzecki: I'm working on a branch with some cleanups, and one of them would be this: https://github.com/mardy/snapd/commit/b1b668b065790b1d741add95c476300c3894fecb [06:50] mardy: the directory could have eisted before, potentially with the wrong permissions [06:50] mborzecki: but if you have a look at the commit I mentioned before (73e89cf8cae423bca52df128e2f8d3508068f55c), you'll see that some of those chowns were added by you [06:51] mborzecki: but the code there calls chmod only if the directory did not exist :-) [06:52] mardy: ah right, heh, should have been `res != 0` [06:53] mardy: possible that this part was running under the real uid at some point [06:54] hm but then mkdirs would fail i think [06:54] mardy: so maybe a bug after all [06:56] mborzecki: but the comment there explicitly says that the chown needs to be done only if we created the dirs, so the "==" is consistent with that [06:57] I saw a comment (or maybe it was a commit message) that stated that we rely on packaging doing the right thing. I think that the current assumption is correct, and that the chown is not needed [07:00] mardy: ok, i see now, take a look at commit 82c8083d64b9af5d35d7b7cfb11d6faeb800e375 [07:01] mardy: now we're flipping both uid and gid, but before we only changed uid, hence mkdir would give ou a directory owned by `0:` [07:03] morning [07:05] mborzecki: oh, that's interesting (and so cool when the git history is so explicative!), thanks! [07:05] pstolowski: hi! [07:39] PR snapd#11786 opened: Mount support cleanups [07:54] mardy: so there are going to be some wsl2 specific files under /var/lib/snapd/lib/ [07:54] ? [08:06] Mardy, is that a response to my pr yesterday, or has someone else been working on wsl2, also? [08:07] mborzecki: if the is a response to my wsl2 pr then maybe we will get wsl libs in that dir. I've marked my pr as draft to get feedback for now: https://github.com/snapcore/snapd/pull/11785 [08:07] PR #11785: RFC: WSL2 GPU support in strict confinement [08:11] Mardy once your pr merges I'll reabse and make changes to my code to match the same usage of the sc_nonfatal_mkdir etv [08:19] PR snapd#11787 opened: portal-info: Add CommonID Field [08:25] diddledani: AFAIK no one else is working on WSL2, I just created my PR after seeing yours [08:26] mardy: I'd like to see the sc_mkdir_and_mount_and_bind function(s) abstracted out to a shared helper location with the nvidia specifics removed (ie. call to `sc_nv_version();` and `sc_probe_nvidia_driver(&version);` bits done in the nvidia files with the mount and bind method simply mounting and binding rather than checking nvidia versions and stsuff [09:05] diddledani: that would make sense, but we can work on it later [09:19] PR snapd#11788 opened: secboot/keymgr: extend unit tests, add helper for identify keyslot used error [10:11] mardy: I think I know what the problem is. If pwd is $HOME, and I play the file, it works. But if I change pwd to the directory the file is in (on sshfs mounted directory), it fails. [10:12] I am still not sure of what the problem, but I do have a workaround now. [10:19] svip: mmm... can you please try starting other snaps while your CWD is somewhere in the sshfs tree? I wonder if this might be a generic problem with snaps [10:20] I've experienced this problem with omxplayer-pi and vlc-pi, but they are both by the same developer, so they might simply share the same issue. [10:20] Do you have any suggestion of a snap I could try? [10:21] svip: the hello-world one :-) [10:21] if that works, then we can try something more complicated, like the chromium one [10:23] mardy: hello-world fails the same way. [10:23] there should be nothing special in either of the snaps (i'm the maintainer) [10:24] mardy: Could it be the way I mount the sshfs volume? I simply do the sshfs command without any flags. [10:24] The external drives just happen to use the same user as me. [10:34] svip: wow, that's cool, in a way. Let me search if we already have a bug for this [10:36] svip: I cannot find anything, would you be so kind to file one? https://bugs.launchpad.net/snapd Or I can do it, if you don't have time [10:37] I can do it. [10:40] sshfs is fuse-based right? the default for fuse filesystems is to block "other users" including root, so snapd will be unable to access the CWD when launching a snapped app [10:41] diddledani: How do I allow others to read from the sshfs mounted directory? [10:41] svip: add `user_allow_other` or `allow_root` in `/etc/fuse.conf` [10:42] sorry I got that wrong [10:42] add `user_allow_other` to `/etc/fuse.conf` then you need to use the `allow_root` option when mounting the fs [10:43] with `user_allow_other` in `/etc/fuse.conf`, run this to mount `sshfs -o allow_root user@server:/source /destination` [10:43] diddledani: That works! Thanks. [10:43] oh, you might not need `user_allow_other` in `/etc/fuse.conf` if you mount with that command [10:44] ref: https://unix.stackexchange.com/questions/17402/why-does-root-get-permission-denied-when-accessing-fuse-directory#:~:text=It%27s%20the%20way%20fuse%20works.%20If%20you%20want,fuse%20filesystem%20with%20allow_other%20or%20allow_root%20as%20options. [10:44] Well, considering it's just me on this machine (a Raspberry Pi), I wouldn't be too worried. [12:01] diddledani: too bad I was not looking at this chat, I just reached the same conclusion. I still think that we could improve this part a bit though, and make snap-confine more transparent about the user (who should not know about these details) [12:25] PR snapd#11789 opened: interfaces: opengl: add rules for NXP i.MX GPU drivers [12:37] PR core-build#58 closed: initramfs: add neccessary modules for rockchip emmc and sdcard [12:50] PR snapd#11790 opened: tests: core20 preseed/nested spread test [14:42] PR snapcraft#3740 opened: repo: enable package repository architectures [15:21] PR snapd#11762 closed: interfaces: tweak getPath() slightly and add some more tests [18:12] PR snapd#11599 closed: tests: use new snaps.name and snaps.cleanup tools [19:17] PR snapcraft#3740 closed: repo: enable package repository architectures [20:32] PR snapd#11791 opened: tests: fix the system-snap-refresh test