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

[Gary E. Miller]

Yo Dave!

On Tue, 23 Jul 2013 11:08:03 -0700
Dave Platt <address@hidden> wrote:

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

Yeah, different device as fas as the kernel knows, but in practice
usually the same device.

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

We are not the udev upstream and can't make their decisions.
 
> (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.

Unix has used group uucp for at least 40 years.  And we need to
be OS/distro agnostic.
 
> (3) Disable privilege dropping in gpsd, with all the potential
>      security risks that entails.

Yeah, not good.
 
> (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.

We have discussed this one before.  We will need to do something
like this so solve the NTP/PPS problem, so might as well consider it
for this problem.

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

We are not the udev upstream and can't make their decisions.  And since
udev is Linux only that locks out the *BSD, OSX, Andoid, and Windows
users.

> 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

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

I go for (2) short term, but we'll need to do (4) for this and other
reasons.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588

signature.asc
Description: PGP signature