Users are not added to the dialout group

Bug #1923363 reported by Dave Jones
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Status tracked in Kinetic
Impish
Won't Fix
Undecided
Unassigned
Jammy
Confirmed
Undecided
Unassigned
Kinetic
Confirmed
Undecided
Unassigned
user-setup (Ubuntu)
Status tracked in Kinetic
Impish
Won't Fix
Undecided
Unassigned
Jammy
Confirmed
Undecided
Unassigned
Kinetic
Confirmed
Undecided
Unassigned

Bug Description

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.

Tags: fr-1316
Revision history for this message
Dave Jones (waveform) wrote :

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

Revision history for this message
Steve Langasek (vorlon) wrote :

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?

Changed in user-setup (Ubuntu):
status: New → Incomplete
Changed in ubiquity (Ubuntu):
status: New → Incomplete
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

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

Revision history for this message
Dave Jones (waveform) wrote :

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

Dave Jones (waveform)
Changed in user-setup (Ubuntu):
status: Incomplete → New
Changed in ubiquity (Ubuntu):
status: Incomplete → New
tags: added: fr-1316
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in ubiquity (Ubuntu):
status: New → Confirmed
Changed in user-setup (Ubuntu):
status: New → Confirmed
Revision history for this message
Łukasz Zemczak (sil2100) wrote :

Is this still a thing for impish?

Changed in user-setup (Ubuntu Impish):
status: Confirmed → Incomplete
Changed in ubiquity (Ubuntu Impish):
status: Confirmed → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in user-setup (Ubuntu Impish):
status: Incomplete → Expired
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in user-setup (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in ubiquity (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in ubiquity (Ubuntu Impish):
status: Incomplete → Expired
Revision history for this message
Dave Jones (waveform) wrote :

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

Changed in ubiquity (Ubuntu Kinetic):
status: Expired → New
Changed in user-setup (Ubuntu Kinetic):
status: Expired → Incomplete
status: Incomplete → New
Changed in user-setup (Ubuntu Impish):
status: Expired → Won't Fix
Changed in ubiquity (Ubuntu Impish):
status: Expired → Won't Fix
Revision history for this message
Dave Jones (waveform) wrote :

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in ubiquity (Ubuntu Jammy):
status: New → Confirmed
Changed in ubiquity (Ubuntu):
status: New → Confirmed
Changed in user-setup (Ubuntu Jammy):
status: New → Confirmed
Changed in user-setup (Ubuntu):
status: New → Confirmed
Dave Jones (waveform)
summary: - [FFe] Users are not added to the dialout group
+ Users are not added to the dialout group
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers