Re: [gpsd-dev] Another release seems called for

[Dave Platt]

> > Depending on platform, if on Linux you can teach udev to set the
> > permissions so that gpsd can access it.
>
> Yeah, I could tweak udev, but gps had no problems opening it to start
> with.  It would be nice if gpsd could still open it for a replug
> without system specific tweaks.

From the point of Linux, it's actually a different device after
the re-plug.  The original device node is unlinked by udev after
the unplug, and a new one (with whatever permissions the udev scripts
are set up for) is created.

The options would seem to be:

(1) Set up the udev rules to grant the appropriate access (read-
    only or read/write) to whatever UID and/or GID the gpsd daemon
    is running in, after it drops privileges.

(2) Assuming that the Linux distributions's default udev rules
    place /dev/ttyUSB* nodes into a specific group, and grant
    read-write permissions to that group (I believe that's true
    on Debian for example), arrange to have gpsd run as a member
    of that group after it drops privileges.

(3) Disable privilege dropping in gpsd, with all the potential
    security risks that entails.

(4) Add a layer of "open and communicate" logic in gpsd, which
    remains running as root after gpsd starts up and serves as
    a proxy to open and re-open devices.

(5) Use udev rules to launch a (root-user) communication proxy
    upon device plug-in, and have this connect to a running gpsd
    and pipe the communication to the daemon (rather than having the
    daemon try to open the device).  I don't know if gpsd has
    this sort of "listen on a socket and allow new gps devices
    to connect and push data" capability.

It *might* be possible to do:

(5) Modify gpsd to not close the device after un-plug, and expect
    that the kernel will magically reconnect the USB device to the
    same internal plumbing after a re-plug and allow the same
    open file descriptor to communicate with it

but I don't believe that the kernel works this way.  Once the device
is unplugged, the internal state is lost and must be re-established
by a new open() to a new device node after re-plug, I think.

Approaches (1) and (2) seem like the cleanest and easiest.