| mup | PR snapd#12153 opened: boot: add factory-reset cases for boot-flags <Created by Meulengracht> <https://github.com/snapcore/snapd/pull/12153> | 06:35 |
|---|---|---|
| mup | PR snapd#12154 opened: overlord: run install-device hook during factory reset <Created by Meulengracht> <https://github.com/snapcore/snapd/pull/12154> | 06:35 |
| eoli3n | Hey mardy | 07:20 |
| eoli3n | this week will be the one we fix it :P | 07:20 |
| eoli3n | i'm full of hope | 07:20 |
| eoli3n | 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:21 |
| eoli3n | ok, i'm testing | 07:36 |
| eoli3n | (see my answer on the thread) | 07:36 |
| eoli3n | thread updated, i'm still searching for a way to trigger permanent nfs-support | 08:10 |
| mup | PR snapd#12155 opened: DT-576 Check the status of refresh-pending snaps <Created by sergio-costas> <https://github.com/snapcore/snapd/pull/12155> | 10:15 |
| mardy | eoli3n: hi! Let me read the forums... | 11:18 |
| eoli3n | (y) | 11:18 |
| mardy | eoli3n: instead of delaying snapd startup, can't you make the mount of the NFS happen earlier? | 11:23 |
| eoli3n | no, because there is no nfs at startup | 11:24 |
| eoli3n | nfs is automounted by autofs when a user log in | 11:24 |
| eoli3n | mardy: i guess, that there is no way to force nfs support permanently ? | 11:24 |
| eoli3n | i don't want snapd auto detection | 11:25 |
| eoli3n | i want to force nfs support permanently, is there a way ? | 11:25 |
| mardy | eoli3n: don't you have an autofs entry in your fstab? | 11:27 |
| eoli3n | no | 11:27 |
| eoli3n | that's not the way autofs work | 11:27 |
| eoli3n | mardy: you should be a politic guy, you are really good at skipping answers :P | 11:28 |
| mardy | 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:30 |
| mardy | 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 |
| eoli3n | there is no autofs entries in fstab | 11:31 |
| eoli3n | AFAIK it doesn't even exist | 11:32 |
| eoli3n | snapd should test if autofs as mounts in /etc/autofs/auto.master.d | 11:32 |
| eoli3n | sorry /etc/auto.master.d | 11:32 |
| eoli3n | if autofs have* mounts | 11:34 |
| eoli3n | could you explain why there is no way to force nfs-support ? | 11:35 |
| eoli3n | that's not what /var/lib/snapd/apparmor/snap-confine/nfs-support file does ? | 11:35 |
| eoli3n | the only problem is to make that file permanent | 11:36 |
| eoli3n | it seems crazy af to me that that file is "moved" by something | 11:36 |
| eoli3n | 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 |
| eoli3n | it sounds like a crazy design | 11:37 |
| mardy | it's snapd removing it | 11:37 |
| mardy | it removes all files from that directory, that were not created by it | 11:38 |
| eoli3n | is there any reason ? | 11:38 |
| eoli3n | i mean, why doing this ? | 11:38 |
| mardy | let me check if I can dig some info out of the git repo | 11:38 |
| eoli3n | ok | 11:38 |
| eoli3n | thanks again for helping | 11:38 |
| mardy | eoli3n: the logic was added here: https://github.com/snapcore/snapd/commit/8db78ad30cb060ad4aab0de3489e5d5060d8c743 | 11:43 |
| eoli3n | mardy: should I fire a bug somewhere ? | 11:44 |
| mardy | 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 |
| mardy | and this seems was not explicitly requested | 11:44 |
| eoli3n | so there is two things, 1° fix autofs test, to guess nfs use not only from fstab, but also /etc/auto.master.d | 11:45 |
| eoli3n | 2° give the ability to trigger nfs-support with a root created file, without removing it | 11:46 |
| mrec | so snap basically eliminates the global IPC/Shared memory support? | 11:46 |
| mrec | backward development in my eyes... certainly flagged as "safety" | 11:47 |
| eoli3n | i could workaround by adding a fake nfs mount, with good systemd options to ignore if fails | 11:47 |
| mardy | eoli3n: I updated https://bugs.launchpad.net/snapd/+bug/1917348 | 11:53 |
| mup | Bug #1917348: NFS access not permitted for snap's on LDAP autofs system <snapd:In Progress by zyga> <https://launchpad.net/bugs/1917348> | 11:53 |
| mardy | mrec: no, we do have the shared-memory interface: https://snapcraft.io/docs/shared-memory-interface | 11:54 |
| ogra | mardy, sadly that doc lacking a description of the "private" attribute which actually allows full /dev/shm access) | 11:56 |
| ogra | +is | 11:56 |
| mrec | 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:19 |
| eoli3n | mardy: is there a way to setup a cacher serveur for packages ? something like apt-cacher ? | 12:20 |
| mrec | 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 |
| mrec | that worked for like 1 1/2 decades | 12:21 |
| ogra | mrec, that is the "private" flag i mentioned above ... it i described in the core that is linked from the doc lage | 12:22 |
| ogra | s/lage/page/ | 12:22 |
| mrec | ok and how about sysv-ipc? | 12:22 |
| ogra | 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:22 |
| ogra | sysv-ipc ? you mean sockets ? | 12:23 |
| mrec | eg. semaphores | 12:23 |
| mrec | message queues | 12:23 |
| mardy | eoli3n: not AFAIK | 12:24 |
| mrec | there should be an easy to set option to give snap packages access to that in order to keep backward compatibility | 12:24 |
| mrec | stripping off everything that has been there for decades cannot be flagged as "security".. certainly if things are removed they cannot be exploited. | 12:25 |
| ogra | 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:26 |
| mrec | let's not use a computer so it cannot be exploited :-) | 12:27 |
| mrec | 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 |
| mrec | 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 |
| ogra | i think semaphores can be handled via the snapcraft-preload wrapper | 12:31 |
| ogra | 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 |
| mrec | we use semaphores eg. to notify the client application that a video frame is ready | 12:33 |
| ogra | i doubt this will change anyt time soon ... | 12:33 |
| mrec | it looks more like security is an excuse for an incomplete system, if security is so important put everything into the browser | 12:34 |
| mrec | destroying sysv ipc is not good | 12:35 |
| mrec | 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 |
| ogra | well, what are the exact erros you did hit with your snap = | 12:36 |
| ogra | did you run it throug the snappy-debug tool yet (it will giv interface suggestions) | 12:37 |
| mrec | 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 |
| mrec | we treat it as a virtual machine (which it is.. due to the sandboxed nature) | 12:37 |
| ogra | right, but if bot snaps do come from the same publisher you can use the shm interface just fine | 12:38 |
| ogra | *both | 12:38 |
| ogra | (or even work without shm interface at all if you peoperly use a snap-named subdir in /dev/shm) | 12:39 |
| mrec | well we got it work but it would still be better to restore full sysvipc support in snap packages | 12:41 |
| mrec | unix domain sockets are also locked no? | 12:41 |
| ogra | IIRC they work inside a snap for IPC | 12:42 |
| mrec | that's so bad... | 12:42 |
| ogra | either way, if you want changes, better start a thread in the snapd category in forum.snapcraft.io | 12:42 |
| mrec | it needs to reach servers outside of the snap package that's what sysv-ipc and domain sockets were introduced for | 12:42 |
| mrec | ok | 12:43 |
| mup | PR snapd#12156 opened: tests: fix unbound SPREAD_PATH variable on nested debug session <Simple 😃> <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/12156> | 12:56 |
| mup | PR snapd#11419 closed: gadget: Use systemd-repart to create new partition during install <Precious but later :heart:> <Created by valentindavid> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/11419> | 13:16 |
| mup | PR snapd#11421 closed: many: Do not use -enc suffix for encrypted parition labels <Precious but later :heart:> <Created by valentindavid> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/11421> | 13:16 |
| mup | PR snapd#12031 closed: systemd: Do not mount snaps before `ostree-remount.service` <Created by valentindavid> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/12031> | 13:21 |
| mup | PR snapd#12132 closed: wrappers: use a revision-agnostic paths when rewriting a desktop file <Needs Samuele review> <Precious but later :heart:> <Created by oSoMoN> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/12132> | 13:36 |
| mup | PR snapcraft#3915 opened: legacy: install unpinned build packages <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/3915> | 15:06 |
| mup | PR snapd#12157 opened: tests: disable quota tests on arm devices using ubuntu core <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/12157> | 15:12 |
| mup | PR snapd#12146 closed: image: update `prepare-image` work with UC20+ style classic models <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/12146> | 15:47 |
| mup | PR snapd#12158 opened: image,tests: tweak naming and test for classic UC20+ image <Created by mvo5> <https://github.com/snapcore/snapd/pull/12158> | 16:02 |
| mup | PR snapcraft#3914 closed: build(deps): bump oauthlib from 3.2.0 to 3.2.1 <dependencies> <python> <Created by dependabot[bot]> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3914> | 23:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!