it would, if it was allowed, /etc/systemd is a protected path it seems, that is what i meant above regarding white-listing.
I tried and seems to work, and afaik it isn’t:
well, i got an error message at snap install time, i’ll have to re-build the snap with layout to give you the exact error message i got on the core18 system i tried it on …
will report back with the error as soon as i have that …
here is the error:
$ sudo snap install --dangerous logsync-james_0.2_amd64.snap
error: cannot perform the following tasks:
- Run configure hook of "logsync-james" snap if present (run hook "configure":
-----
cannot update snap namespace: cannot write to "/etc/systemd/journal-upload.conf" because it would affect the host in "/etc/systemd"
snap-update-ns failed with code 1: File exists
-----)
using snapcraft.yaml and configure hook as in:
I dug a little deeper, seems the above happens when the target file does not exist at all.
It seems bind-mounting the whole of /etc/systemd in the layout instead works with some additional changes to the configure hook … I created a PR for @jamesj to merge that should make the package go through without manual review… (we might want to ask for auto-connections of the interfaces though, up to james)
This is likely related to https://bugs.launchpad.net/snapd/+bug/1843423
1 Like
It looks like things start to work with the bind: $SNAP_DATA/systemd layout (great!). I noticed the snap is called ‘logsync-james’. Is this meant to be an officially supported snap or technique (thinking through my own and others use (ref. Change in logging behaviour on Ubuntu Core))
i just uploaded Install logsync-receiver on Linux | Snap Store and will write a doc here in the forum how to set up both sides (well, essentially you only need to set the ip on the client with a snap set command).
i think initially james only wanted to make a proof of concept … but given how well this setup actually works and how easy it is the client snap should probably be re-named to logsync 
1 Like
i created
1 Like
Exactly, it was just a proof-of-concept to show an approach to remote debugging a device. I guess I could rename it now that @ogra has removed the need for the system-files interface.
1 Like
Some of these I find interesting. I suggest once the name is changed, following Process for aliases, auto-connections and tracks - #11 by jdstrand and we can discuss why it needs some of these interfaces.
the exotic ones (time-control, daemon-notify, network-control) are just for quietening systemd log spam, they are technically not needed for the app to work …
dropping everything but log-observe, network and network-bind gets me the following log output (yet with a properly working app):
Dez 14 12:37:13 anubis systemd[1]: Started Service for snap application logsync-james.upload.
Dez 14 12:37:13 anubis audit[9713]: AVC apparmor="DENIED" operation="open" profile="snap.logsync-james.upload" name="/proc/1/environ" pid=9713 comm="systemd-journal" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Dez 14 12:37:13 anubis audit[9713]: AVC apparmor="DENIED" operation="capable" profile="snap.logsync-james.upload" pid=9713 comm="systemd-journal" capability=12 capname="net_admin"
Dez 14 12:37:13 anubis audit[9713]: AVC apparmor="DENIED" operation="sendmsg" profile="snap.logsync-james.upload" name="/run/systemd/notify" pid=9713 comm="systemd-journal" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
Dez 14 12:37:13 anubis audit[9713]: AVC apparmor="DENIED" operation="sendmsg" profile="snap.logsync-james.upload" name="/run/systemd/notify" pid=9713 comm="systemd-journal" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
Dez 14 12:37:13 anubis kernel: audit: type=1400 audit(1576323433.449:4075): apparmor="DENIED" operation="open" profile="snap.logsync-james.upload" name="/proc/1/environ" pid=9713 comm="systemd-journal" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Dez 14 12:37:13 anubis kernel: audit: type=1400 audit(1576323433.449:4076): apparmor="DENIED" operation="capable" profile="snap.logsync-james.upload" pid=9713 comm="systemd-journal" capability=12 capname="net_admin"
Dez 14 12:37:13 anubis kernel: audit: type=1400 audit(1576323433.449:4077): apparmor="DENIED" operation="sendmsg" profile="snap.logsync-james.upload" name="/run/systemd/notify" pid=9713 comm="systemd-journal" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
Dez 14 12:37:13 anubis kernel: audit: type=1400 audit(1576323433.449:4078): apparmor="DENIED" operation="sendmsg" profile="snap.logsync-james.upload" name="/run/systemd/notify" pid=9713 comm="systemd-journal" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
I am also observing similar “sendmsg - denied” messages with my snap .Can we ignore this error messages in a strict confinement?
This thread is very old @jithcr - please feel free to open a new thread under the snap category for help with that.