Users are not added to the dialout group

[Dave Jones]

We're attempting to make the GPIO system on the Raspberry Pi images work "out of the box" on the new image. By default, GPIO kernel devices are made available to members of the "dialout" group which the initial user is added to by default on our server images. However, we've noticed that this isn't the case on the desktop images.

The regression potential is minimal; the group already exists and we're simply adding the freshly created user to a new group and not removing any existing memberships. The group in question ("dialout") is also rarely used these days except for providing access to serial consoles, and as mentioned above is already a default membership on the server images. The change has been tested on the desktop image successfully.

A test build of the updated image will be made under https://launchpad.net/~waveform/+archive/ubuntu/ubiquity and I'll attach a debdiff shortly.

[Dave Jones (waveform)]

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

[Steve Langasek (vorlon)]

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?

[Dimitri John Ledkov (xnox)]

@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?

[Dave Jones (waveform)]

@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.

[Launchpad Janitor (janitor)]

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

[Łukasz Zemczak (sil2100)]

Is this still a thing for impish?

[Launchpad Janitor (janitor)]

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

[Launchpad Janitor (janitor)]

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

[Launchpad Janitor (janitor)]

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

[Launchpad Janitor (janitor)]

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

[Dave Jones (waveform)]

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

[Dave Jones (waveform)]

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

[Launchpad Janitor (janitor)]

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