Grant access to hardware (UARTs, I2C, etc.) via custom udev rules

Attach debdiff for user-setup. This will need uploading before ubiquity's copy of the package can be sync'd.

I'm unclear why the default user is part of the dialout group on server images either. If you look at the history of user-setup, you'll see that we once (10 years ago) had the default user in dialout, but this was reverted because it wasn't needed for ppp access (that uses dip) and users shouldn't have direct access to serial ttys by default. In particular, if there is a serial console, having access to the tty means the user may have access to intercept root passwords being sent on the line.

Do you know where the dialout group is being added by default on servers, and if there has already been discussion of this issue?

I expect that the GPIO devices are not serial TTYs. Is there a good reason to use the dialout group for these devices instead of a different (perhaps new) group?

@vorlon this is the same user that already is in `sudo` & `lxd` groups, thus they can do that anyway.

To use the real UART rx/tx pins one has to disable bluetooth and use /dev/ttyAMA0

For gpio pins, I see that some use group `gpio` and then mark /dev/gpiomem to be owned by gpio group.

We should be able to create a new groupname and use that one, as long as the udev rule for it has the matching group.

Dave, is this to access ttyAMA0 or to access something else? i2c, gpiomem, etc?

@vorlon on the question of where it's added by default, that's in the cloud-init default configuration which lives in /etc/cloud/cloud.cfg and contains the following stanza (redacted for brevity):

system_info:
    ...
    default_user:
        ...
        groups: [adm, audio, cdrom, dialout, dip, floppy, lxd, netdev, plugdev, sudo, video]

I'd echo xnox's point that as the user is being added to adm and sudo, I don't think there's any particular security concern here.

On the subject of choice of groups, it would be nice to echo raspios' setup which is to use a "gpio" group to permit access to the GPIO related devices (/dev/gpiomem, /dev/gpiochip*), an "spi" group for the SPI buses (/dev/spidev*), and an "i2c" group for the I2C buses (/dev/i2c-*).

However, I ran out of time to go fiddling with defining new groups and ensuring the default user is in all those new groups on both the desktop and server images. Upstream in Debian (and hence in Ubuntu), "dialout" is already used for GPIO access (which makes sense given the serial pins are part of the GPIO header, just like SPI and I2C), and (as noted above) we already add the user to this group on the server image, so it seems a reasonable approach to achieve the ultimate goal of providing the default user access to the GPIO header without having to jump to root to do so.

And just to answer @xnox's query as to what exactly this is for, it's access to the GPIO header as a whole, including i2c, gpiomem (although ideally gpiochip* actually as that's the preferred device to use for GPIO access now), etc. just in case that's not clear from the above.

Status changed to 'Confirmed' because the bug affects multiple users.

Is this still a thing for impish?

[Expired for user-setup (Ubuntu Impish) because there has been no activity for 60 days.]

[Expired for user-setup (Ubuntu) because there has been no activity for 60 days.]

[Expired for ubiquity (Ubuntu) because there has been no activity for 60 days.]

[Expired for ubiquity (Ubuntu Impish) because there has been no activity for 60 days.]

Argh, this slipped off my radar; yes, it was still a thing in impish *and* jammy.

I'll rebase the patch and check it still works on a modern image.

Status changed to 'Confirmed' because the bug affects multiple users.

This additionally causes issues with accessing certain /dev/video* devices for hardware acceleration, which is probably quite an important feature for the desktop image.

Added the video group, rebased the debdiff for kinetic, and generated it with git-diff instead of debdiff (apparently debdiff doesn't understand symlinks).

There will be no further releases of lunar; hence won't fix for this release

Re-generated for mantic (and refined the changelog entry a bit too)

Adding a merge request for ubiquity as it turns out the user-setup embedded in ubiquity is not the one from the archive (yet?).

Per vorlon's comments on the merge request, I've closed the merge and will re-submit an alternative method using udev rules instead of group membership. Adding ubuntu-settings for the udev rules, and cloud-init as we presumably want to remove membership in those groups from server instances too.

Added PR for cloud-init to remove the default groups that were removed (ages ago) from the desktop image (excepting the lxd group which was added in a reasonably recent commit and so is presumably wanted): https://github.com/canonical/cloud-init/pull/4258

This bug was fixed in the package cloud-init - 23.3~4ga31370af-0ubuntu1

---------------
cloud-init (23.3~4ga31370af-0ubuntu1) mantic; urgency=medium

  * Upstream snapshot based on upstream/main at a31370af.
    - Bugs fixed in this snapshot: (LP: #1923363, #2028562, #2028784)
  * d/cloud-init.maintscript: Remove the unused hook-network-manager
    conffile. (LP: #2027861)
  * d/control: Add python3-passlib as needed for testing

 -- James Falcon <email address hidden> Mon, 31 Jul 2023 11:38:42 -0500

Does this have FFe?

it does now

This bug was fixed in the package ubuntu-settings - 23.10.5

---------------
ubuntu-settings (23.10.5) mantic; urgency=medium

  * ubuntu-raspi-settings: Add macb ethernet driver to the eth0 rename list
    to support Raspberry Pi 5 (LP: #2037642)
  * ubuntu-raspi-settings: Use uaccess instead of group membership to control
    access to GPIO devices (LP: #1923363)
  * ubuntu-settings, ubuntu-raspi-settings-desktop: Override lintian warnings
    about netplan configuration mode and growroot.service

 -- Dave Jones <email address hidden> Fri, 22 Sep 2023 11:13:46 +0100