Classic confinement for "pebble"

store-requests
#1

Hi!

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.

Refs:

#2

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.

#3

Sure! Here it goes:

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.

#4

Hello @cjdc , it seems that classic is required but before we continue can you point us in which supported classic category do you think pebble fits in? Process for reviewing classic confinement snaps

#5

Hi. I’d say it falls into the “orchestration software” category.

#6

Hi @cjdc,

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?

#7

Hi @emitorino, thanks for the reply.

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.

#8

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.

#9

@cjdc, @sergiusens,

Thanks for the extra clarifications. Requirements for classic confinement are understood. I have vetted the publisher. This is now live.