Allow installation and auto-connection of mulitple interfaces for console-conf snap

store-requests
1

Hi,

As part of the UC24 work, console-conf which was originally part of the boot base snap has been moved to a snap which users can optionally include when building Ubuntu Core images.

In short, console-conf provides an onboarding experience for Ubuntu Core systems, as such, it allows to set up the network (via netplan), add an initial user (by talking to snapd over /run/snapd.socket).

The original code lives under https://github.com/canonical/subiquity and the snap is packaged in this repository: https://github.com/snapcore/console-conf-snap

I have already opened a request to transfer the ownership of the snap to the ‘canonical’ account in Transfer `console-conf` to canonical and requested a 24 track in Request for '24' track for 'console-conf'

I have published a revision of a snap which does not use interfaces that have allow-installation: false in the snapd base declaration, but we are otherwise blocked form using the snap in UC24.

I would like to request the following.

Auto connections

  • hardware-observe
  • network-observe
  • network-control
  • network-setup-control

These are all required for setting up a network configuration and then applying it using netplan.

Allow-installation and auto-connect

  • snapd-control - this is required to request snapd to create a user to claim the device

  • system-files defined as:

    console-conf-runtime-support:
  interface: system-files
  write:
    - /run/console-conf
    - /var/log/console-conf

    The /var/log/console-conf is where logs are stored by default. /run/console-conf is the runtime state and is used to pass data from unconfined service wrappers executing from the boot base

  • custom-device defined as:

plugs:
 terminal-control:
   interface: custom-device
slots:
 terminal-devices:
   interface: custom-device
   custom-device: terminal-control
   # XXX this could use x11/wayland/mir interface, but we only need a subset of
   # the permissions provided by each
   devices:
     - /dev/tty[0-9]
     - /dev/ttyS[0-9]
   udev-tagging:
     - kernel: tty[0-9]
       subsystem: tty
     - kernel: ttyS[0-9]
       subsystem: tty

The main console-conf proces inherits the file descriptor of a tty device from its shell wrapper executed by systemd as console-conf@<tty> service. However, when executing as a recovery system chooser, console-conf is communicating with snap-recovery-chooser over stdin/stdout and needs to open appropriate /dev/tty* itself. I looked at x11/wayland/mir, but the slot side gives a lot of permissions that are not needed here.

Please see https://github.com/snapcore/console-conf-snap/blob/main/snap/snapcraft.yaml for further reference.

1 Like
2

@review-team gentle ping

3

+1 for auto-connecting: hardware-observe, network-observe, network-control, network-setup-control given console-conf’s functionality in applying network configs via netplan.

+1 for auto-connecting: console-conf-runtime-support as the files are owned by the snap itself. I’d also recommend splitting this into 2 system-files interface requests such as run-console-conf and var-log-console-conf

+1 for custom-device given your explanation of the need to open /dev/tty* itself in recovery system chooser.

snapd-control is a very privileged interface but it seems necessary due to the need to create a user to claim the device. So a tentative +1 pending review from other @reviewers

4

For more context, especially for snapd-control supper privileged interface request.

console-conf snap is part of device onboarding experience and such has only meaning on the first boot so it has to be purposely added to the image at the device image build time. Furthermore, console-conf does not have any service(s), it has to be manually invoked to proceed. These features further limit misuse of this snap. console-conf assumes physical access to the device as it only interacts through tty. As such this is valid use case for device onboarding. If device has onboarding disabled (through gadget defaults), console-conf is not invoked. Installing console-conf on provisioned system would not bring any advantage as

  • it would have to be manually invoked
  • refuses to proceed to the user creation as there is safety check if device is already provisioned
  • even if this check would be skipped, another check is done on the snapd side
1 Like
5

Hi @ondra @mborzecki1

I agree @cav, hardware-observe, network-observe, network-control, network-setup-control, custom-device and snapd-control interfaces seems to be aligned with the intended functionality of the snap. Even if the use of snapd-control should be kept limited (considering how powerful it is), this looks like a good exception.

Regarding system-files, I would also like to see it split in two different interfaces with names, run-console-conf and var-log-console-conf to be consistent with the usual naming convention for personal-files and system-files interfaces.

Once the change to the system-files would be applied, it is also a +1 from for this request. As we already have two votes for, the voting period has ended and the publisher is already vetted I will make the changes live once the new revision including all the requested interfaces is upload to the store.

Thanks

1 Like
6

Thank you. I’ve updated plug names in https://github.com/snapcore/console-conf-snap/pull/22 but I’m unable to upload a new snap since some of the interfaces have allow-installation: false. Please advice on how you want to proceed.

7

Hello everyone,

+1 from me as well for the requested auto-connections since are clearly required for network configuration as described. I am only wondering if network-control could be enough? or is it network-observe also required ? Anyhow I am granting all to unblock this request, but if not needed we can revert it later. +3 votes for, 0 votes against, this is now live.

Thanks for the detailed explanation and context around device onboarding @ondra . I am not very familiar with the use case here, but from what I read in the ubuntu core doc this is needed to import the user assertions through snapd over /run/snapd.socket as explained. I am not aware of other mechanism to do it so I am +1 as well to grant this and allow the user setup functionality to properly work. +3 votes for, 0 votes against, this is now live. @reviewers please check this in case a less privileged alternative is available.

I am +1 as well for the remaining requests and since we have enough votes, this is all now live.

@mborzecki1 I noticed revision #16 was manually uploaded (since I don’t see the GH build log available) and then #17 was rejected. So let us know if there is any further issue with following releases.

8

Please proceed with reviewing revision 16. Rev 17 wa pushed from the CI build which was started long before I manually uploaded rev 16 and it spent a long waiting on LP build queues.

9

I can confirm that the assertions are now in the store and rev 16 which I released to edge works as expected with all connections established automatically.

2 Likes