[06:35] PR snapd#12153 opened: boot: add factory-reset cases for boot-flags [06:35] PR snapd#12154 opened: overlord: run install-device hook during factory reset [07:20] Hey mardy [07:20] this week will be the one we fix it :P [07:20] i'm full of hope [07:21] i think that i need to reread the whole post, and try to make a state post to figure "where we are now" to be able to find "what we could try, or what we miss" [07:36] ok, i'm testing [07:36] (see my answer on the thread) [08:10] thread updated, i'm still searching for a way to trigger permanent nfs-support [10:15] PR snapd#12155 opened: DT-576 Check the status of refresh-pending snaps [11:18] eoli3n: hi! Let me read the forums... [11:18] (y) [11:23] eoli3n: instead of delaying snapd startup, can't you make the mount of the NFS happen earlier? [11:24] no, because there is no nfs at startup [11:24] nfs is automounted by autofs when a user log in [11:24] mardy: i guess, that there is no way to force nfs support permanently ? [11:25] i don't want snapd auto detection [11:25] i want to force nfs support permanently, is there a way ? [11:27] eoli3n: don't you have an autofs entry in your fstab? [11:27] no [11:27] that's not the way autofs work [11:28] mardy: you should be a politic guy, you are really good at skipping answers :P [11:30] eoli3n: sorry, I did look up the code and indeed saw that there's no way to force nfs support, but I was looking for workarounds [11:31] eoli3n: if snapd sees a nfs or autofs entry in the fstab, it will enable it. I wonder if there's a way to add an entry there, which is basically a no-op [11:31] there is no autofs entries in fstab [11:32] AFAIK it doesn't even exist [11:32] snapd should test if autofs as mounts in /etc/autofs/auto.master.d [11:32] sorry /etc/auto.master.d [11:34] if autofs have* mounts [11:35] could you explain why there is no way to force nfs-support ? [11:35] that's not what /var/lib/snapd/apparmor/snap-confine/nfs-support file does ? [11:36] the only problem is to make that file permanent [11:36] it seems crazy af to me that that file is "moved" by something [11:37] that's like create /etc/something.conf, chattr +i the file and then a daemon fails to start because of the chattr +i [11:37] it sounds like a crazy design [11:37] it's snapd removing it [11:38] it removes all files from that directory, that were not created by it [11:38] is there any reason ? [11:38] i mean, why doing this ? [11:38] let me check if I can dig some info out of the git repo [11:38] ok [11:38] thanks again for helping [11:43] eoli3n: the logic was added here: https://github.com/snapcore/snapd/commit/8db78ad30cb060ad4aab0de3489e5d5060d8c743 [11:44] mardy: should I fire a bug somewhere ? [11:44] I think it's clear that we needed to ensure that the file contents were the expected ones, but the EnsureDirState function also removed unrecognized files, [11:44] and this seems was not explicitly requested [11:45] so there is two things, 1° fix autofs test, to guess nfs use not only from fstab, but also /etc/auto.master.d [11:46] 2° give the ability to trigger nfs-support with a root created file, without removing it [11:46] so snap basically eliminates the global IPC/Shared memory support? [11:47] backward development in my eyes... certainly flagged as "safety" [11:47] i could workaround by adding a fake nfs mount, with good systemd options to ignore if fails [11:53] eoli3n: I updated https://bugs.launchpad.net/snapd/+bug/1917348 [11:53] Bug #1917348: NFS access not permitted for snap's on LDAP autofs system [11:54] mrec: no, we do have the shared-memory interface: https://snapcraft.io/docs/shared-memory-interface [11:56] mardy, sadly that doc lacking a description of the "private" attribute which actually allows full /dev/shm access) [11:56] +is [12:19] mardy: this defines that 2 snap packages can communicate with each other, but how about a native application and a snap package accessing the native application via IPC / shared memory? [12:20] mardy: is there a way to setup a cacher serveur for packages ? something like apt-cacher ? [12:21] we just have this situation we have a video server which is providing the data via shm/ipc and regular applications are connecting via the system hooks. Now the snap package disallows all that and won't work. [12:21] that worked for like 1 1/2 decades [12:22] mrec, that is the "private" flag i mentioned above ... it i described in the core that is linked from the doc lage [12:22] s/lage/page/ [12:22] ok and how about sysv-ipc? [12:22] mrec, note though that this will make your snap go into manual review and it will have to undergo inspection by the security team to be allowed into the store [12:23] sysv-ipc ? you mean sockets ? [12:23] eg. semaphores [12:23] message queues [12:24] eoli3n: not AFAIK [12:24] there should be an easy to set option to give snap packages access to that in order to keep backward compatibility [12:25] stripping off everything that has been there for decades cannot be flagged as "security".. certainly if things are removed they cannot be exploited. [12:26] well, age des nto tell anything about how secure something is ... if you lived without doorlocks in your house for three decades that doesnt mean adding a lock is not adding security 🙂 [12:27] let's not use a computer so it cannot be exploited :-) [12:31] that was basically the reason why people preferred linux over windows because linux gave freedom, but now it's going the other way. [12:31] no certainly full ipc and shared memory support has to be supported - and not only by security review but also as an option for the user to set it himself. [12:31] i think semaphores can be handled via the snapcraft-preload wrapper [12:33] well, this is not how snaps are designed ... security checks happen on upload *before* anything goes into the store ... if something uses a super privileged interface that allows breaking out of the sandbox, it goes into manual review [12:33] we use semaphores eg. to notify the client application that a video frame is ready [12:33] i doubt this will change anyt time soon ... [12:34] it looks more like security is an excuse for an incomplete system, if security is so important put everything into the browser [12:35] destroying sysv ipc is not good [12:36] especially if the underlying system supports it... if someone wants that fool proof system he can remove it from the kernel (it's just an option) [12:36] well, what are the exact erros you did hit with your snap = [12:37] did you run it throug the snappy-debug tool yet (it will giv interface suggestions) [12:37] the problem is basically that the snap package does not recognize the host server, so we modified the snap package itself and included the server into the snap package as a workaround [12:37] we treat it as a virtual machine (which it is.. due to the sandboxed nature) [12:38] right, but if bot snaps do come from the same publisher you can use the shm interface just fine [12:38] *both [12:39] (or even work without shm interface at all if you peoperly use a snap-named subdir in /dev/shm) [12:41] well we got it work but it would still be better to restore full sysvipc support in snap packages [12:41] unix domain sockets are also locked no? [12:42] IIRC they work inside a snap for IPC [12:42] that's so bad... [12:42] either way, if you want changes, better start a thread in the snapd category in forum.snapcraft.io [12:42] it needs to reach servers outside of the snap package that's what sysv-ipc and domain sockets were introduced for [12:43] ok [12:56] PR snapd#12156 opened: tests: fix unbound SPREAD_PATH variable on nested debug session [13:16] PR snapd#11419 closed: gadget: Use systemd-repart to create new partition during install [13:16] PR snapd#11421 closed: many: Do not use -enc suffix for encrypted parition labels [13:21] PR snapd#12031 closed: systemd: Do not mount snaps before `ostree-remount.service` [13:36] PR snapd#12132 closed: wrappers: use a revision-agnostic paths when rewriting a desktop file [15:06] PR snapcraft#3915 opened: legacy: install unpinned build packages [15:12] PR snapd#12157 opened: tests: disable quota tests on arm devices using ubuntu core [15:47] PR snapd#12146 closed: image: update `prepare-image` work with UC20+ style classic models [16:02] PR snapd#12158 opened: image,tests: tweak naming and test for classic UC20+ image [23:41] PR snapcraft#3914 closed: build(deps): bump oauthlib from 3.2.0 to 3.2.1