New issue by SorrelArticulata on void-packages repository

https://github.com/void-linux/void-packages/issues/40858

Description:
### Is this a new report?

Yes

### System Info

Void 5.19.17_1 x86_64 GenuineIntel uptodate rFFFFFFFFFFF

### Package(s) Affected

gpsd-3.24_2

### Does a report exist for this bug with the project's home (upstream) and/or another distro?

_No response_

### Expected behaviour

1. Plug in USB GPS source (mine is a u-blox 7)
2. Verify it works and has a GPS lock using gpsmon as root.  This tool directly talks to the GPS device rather than needing gpsd to be working.

``` # gpsmon /dev/ttyACM0 ```

3. Stop gpsmon

4. Start gpsd daemon in one terminal (as root, with verbose debugging flags like this)

```# gpsd -N -F /run/gpsd.sock -D5 /dev/ttyACM0```

5. Run cgps (or any other gps client) in another terminal.  This will talk to gpsd and (if everything is working) give you similar output to what gpsmon did.

``` $ cgps ```

### Actual behaviour

cgps fails to see any data and gpsd spits the following errors:

```
gpsd:PROG: CORE: gpsd_open(/dev/ttyACM0) fd -1
gpsd:PROG: SER: gpsd_serial_open(/dev/ttyACM0) sourcetype 12 fd -1
gpsd:INFO: SER: opening GPS data source type 12 at '/dev/ttyACM0'
gpsd:ERROR: SER: device open of /dev/ttyACM0 failed: Permission denied(13) - retrying read-only
gpsd:ERROR: SER: read-only device open of /dev/ttyACM0 failed: Permission denied(13)
gpsd:ERROR: /dev/ttyACM0: device activation failed, freeing device.
```

Looking at the running process list reveals that the gpsd process has changed to the 'gpsd' user. 

Permissions for the serial device:
```
$ ls -lh /dev/ttyACM0 
crw-rw---- 1 root dialout 166, 0 Nov 30 22:38 /dev/ttyACM0
```

Adding the gpsd user to the dialout group does NOT fix the problem.

Allowing anyone rw access to the serial device DOES fix the problem temporarily
```
# chmod a+x /dev/ttyACM0
```

According to the gpsd manpage:

>       Before doing any processing of GPS data, it tries to drop root
>       privileges by setting its UID to "nobody" (or another configured
>       userid) and its group ID to the group of the initial GPS passed on the
>       command line — or, if that device doesn’t exist, to the group of
>       /dev/ttyS0.

I do not understand how processes can have group ids, but regardless this feature does not seem to be working as intended.

The srcpkg template has this line in it, not sure if it is related to this problem or not:

```make_build_args="dbus_export=0 gpsd_user=gpsd gpsd_group=gpsd```



### Steps to reproduce

See above.