Manual review of logsync snap

[jdstrand]

This seems reasonable for the snap, but in Change in logging behaviour on Ubuntu Core there was discussion that core itself might ship systemd-journal-remote itself and allowing the use of system-files as specified for this snap might break that functionality. @pedronis can you comment? This could potentially be avoided by disallowing the snap write access to /etc/systemd/journal-upload.conf and having the user have to write out /etc/systemd/journal-upload.conf for the snap to read (at least then, it is an overt administrative action).

Before reviewers vote, @pedronis, can you comment on the above?

[pedronis]

Before reviewers vote, @pedronis, can you comment on the above?

yes, it will take me a bit to form a comment though, I wasn’t involved in those discussions originally

[ogra]

note that none of the interface stuff would be necessary if /etc/systemd/journal-upload.conf could be re-mapped inside the snap via a layout (which is forbidden due to its location). it would also not be necessary to worry if the file exists on the host already in this case …

i wonder if the layouts code couldnt just whitelist this particular file for re-mapping and we could forget about the interface at all …

[jamesj]

Having the remote journal export configuration as an option in snapd may be a better long-term approach. This snap may help to fill a gap in the short-term.

[jdstrand]

Well, adding the binary to core/core18/core20 and exposing the config via snap set should be able to go fast once people have decided that is the direction (it after all wouldn’t be tied to a snapd release).

[ogra]

well, given the fact that you need to import a bunch of certificates to gain https forwarding, i fear it wont be that fast.

plain http is surely quick though (just an on/off toggle in the config), but for https we need a configuration tool that imports the certs into the system.

[jdstrand]

I’m thinking about this as basically a request for remote syslog support, and traditional remote syslogging does not use certificates, so, IME, adding plain immediately and then adding certificate support later seems ‘ok’. This is just my opinion of course and will defer to @pedronis and the snapd team’s plans in this area.

[pedronis]

@jamesj Since this snap provides the systemd-journal-remote package internally via stage-packages , I wonder why it wants to use the host’s /etc/systemd/journal-upload.conf instead of it’s own private version of this file?

I’m thinking about this as basically a request for remote syslog support, and traditional remote syslogging does not use certificates, so, IME, adding plain immediately and then adding certificate support later seems ‘ok’. This is just my opinion of course and will defer to @pedronis and the snapd team’s plans in this area.

Wouldn’t something like this side-step the issues for a while:

layout:
   /etc/systemd/journal-upload.conf:
     bind-file: $SNAP_DATA/etc/journal-upload.conf

(that’s one the original use cases for layouts)

Then the snap doesn’t need afaict system-files and it will have “snap set” ways to write the config.

[ogra]

Wouldn’t something like this side-step the issues for a while:

it would, if it was allowed, /etc/systemd is a protected path it seems, that is what i meant above regarding white-listing.

[pedronis]

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:

Snap layouts

<target-path> can include nearly any path except for:

• /proc
• /sys
• /dev
• /run
• /boot
• /lost+found
• /media
• /var/lib/snapd
• /var/snap
• /home
• /tmp

[ogra]

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 …

[ogra]

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:

https://paste.ubuntu.com/p/xKBccrxPgH/

[ogra]

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)

drop priv interface, properly switch to layout

[zyga]

This is likely related to https://bugs.launchpad.net/snapd/+bug/1843423

[jdstrand]

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))

[ogra]

i just uploaded https://snapcraft.io/logsync-receiver 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

[ogra]

i created

Remote Logging on Ubuntu Core

When using Ubuntu Core in appliance setups it is often helpful to have a centralized log server where all devices send their logs. To set this up on Ubuntu Core you can easily install the logsync-james snap on the devices, then connect the necssary interfaces with: snap connect logsync-james:daemon-notify snap connect logsync-james:time-control snap connect logsync-james:network-control snap connect logsync-james:log-observe Now install the logsync-receiver snap on the machine that should act…

[jamesj]

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

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.

[jdstrand]

then connect the necssary interfaces with: snap connect logsync-james:daemon-notify snap connect logsync-james:time-control snap connect logsync-james:network-control

Some of these I find interesting. I suggest once the name is changed, following Process for aliases, auto-connections and tracks and we can discuss why it needs some of these interfaces.

[ogra]

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