I have built a snap for pebble (https://github.com/canonical/pebble). Looking at the guidelines, I believe Pebble falls into the Supported categories, mainly due to:
the dynamic Pebble data and socket paths ($PEBBLE and $PEBBLE_SOCKET), which default to, respectively, /var/lib/pebble/default and /var/lib/pebble/default/.pebble.socket
the user-defined Pebble layers go into ${PEBBLE}/layers
Pebble services will call out to executables that might be located anywhere in the host filesystem
Pebble also offers exec capabilities
While I guess system-file could be used to enable strict confinement for this Snap, I’m afraid it would constrain quite a bit the user experience.
Regarding $PEBBLE and $PEBBLE_SOCKET could these be located within $SNAP_DATA or $SNAP_COMMON instead?
Can you explain more about the executables that pebble calls out to and the other exec capabilities? If access to arbitrary, user-defined binaries is required then there is no way to achieve this unless classic confinement is used - so if you can help me understand more about these functions of pebble that would be great.
could these be located within $SNAP_DATA or $SNAP_COMMON instead?
Yes. At least in theory, since I couldn’t make it fully work just by using those paths (Pebble starts, but hangs…I’d need to dig further to understand why).
Can you explain more about the executables that pebble calls out to and the other exec capabilities? If access to arbitrary, user-defined binaries is required then there is no way to achieve this unless classic confinement is used - so if you can help me understand more about these functions of pebble that would be great.
It is exactly what you’re alluding to -> Pebble is a service manager. Analogously to supervisord or s6, Pebble will load one or more services that are declaratively defined via YAML layers (in $PEBBLE/layers). These services all have a command (https://github.com/canonical/pebble#layer-specification):
# (Required in combined layer) The command to run the service. The
# command is executed directly, not interpreted by a shell.
#
# Example: /usr/bin/somecommand -b -t 30
So yes, a Pebble service’s command can be any arbitrary and user-defined binary.
Pebble exec is similar. It is a client-side Pebble feature to allow the user to execute arbitrary commands. These behave exactly like docker exec - they are one-shot commands sent to the Pebble server. Example: pebble exec touch /tmp/foo.
Have you tried using system-files instead to access the defaults $PEBBLE and $PEBBLE_SOCKET dirs in /var/lib?
Although this category is supported for running workloads on systems without traditional users, I see we have granted classic for similar situations in the past. Still, we are seeing snaps like juju moving to strict confinement so I wonder if you could explore alternatives to make pebble a strictly confined snap instead. @pedronis can you weight in?
Have you tried using system-files instead to access the defaults $PEBBLE and $PEBBLE_SOCKET dirs in /var/lib?
Yes, without success (but I didn’t dig any further to be able to say whether it was my fault it wasn’t working). However, even if that worked, I don’t think it would be enough, since pebble needs to support running arbitrary commands in the system. For example, the user can do pebble exec ls /etc or pebble add new-label /path/to/some/file, and more…meaning that access to any part of the filesystem is expected.
Although this category is supported for running workloads on systems without traditional users, I see we have granted classic for similar situations in the past. Still, we are seeing snaps like juju moving to strict confinement so I wonder if you could explore alternatives to make pebble a strictly confined snap instead. @pedronis can you weight in?
afaik, Juju is a bit different, since it is meant to operate “external” infrastructures. Pebble, otoh, is more like systemd, supervisord, s6, s6-overlay…it’s a process control manager - Pebble will literally launch a local server to run user-defined processes.
The purpose of pebble is to manage processes. It would need access to the host filesystem and the capability of executing random things from there; as declared in the user created pebble layer, which can look something like this:
summary: Simple layer
description: |
A better description for a simple layer.
services:
srv1:
override: replace
summary: Service summary
command: /bin/nextcloudd # I made this up
startup: enabled
after:
- srv2
before:
- srv3
requires:
- srv2
- srv3
environment:
VAR1: val1
VAR2: val2
VAR3: val3
srv2:
startup: enabled
command: /opt/mysql/bin/mysql
before:
- srv3
srv3:
command: /usr/bin/httpd
Pebble could be considered a lightweight process manager, lightly akin to systemd, but for tighter workloads.
For which I +1 the proposal for classic confinement.
