[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] PPS and privilege-dropping

From: Harlan Stenn
Subject: Re: [gpsd-dev] PPS and privilege-dropping
Date: Thu, 17 Oct 2013 22:54:10 +0000

"Gary E. Miller" writes:
> On Thu, 17 Oct 2013 20:11:08 +0000
> Harlan Stenn <address@hidden> wrote:
> > "Eric S. Raymond" writes:
> > >=20
> > > The JSON PPS messages were designed with a specific purpose in mind
> > > - to track the skew between NTP-adjusted system clock and GPS+PPS
> > > time so Dave Taht and I can benchmark NTP.
> >=20
> > And there was much rejoicing.
> Can you tell me what you think it is doing, and where in the gpsd
> code this is generated.  I see nothing like described anywhere near
> the timekeeping code in gpsd.

I have no idea on this one.  Eric and Dave Taht, otoh...

> > >> ALL ntpd prefers root for initialization.  There is serious loss of
> > >> functionality when not initialized as root.
> > >=20
> > > The HOWTO should explain this.  There's a reference to it in a
> > > comment in ntpshm.c, but it didn't tell me enough to understand
> > > *why*.
> >=20
> > I'm not sure what is meant here.  Some of the things ntpd needs root
> > for include opening port 123, sometimes updating the time, and there
> > may also be an issue for shmget() units 0 and 1 (which are 0600
> > perms, while units 2 and 3 are 0666).  There may be other cases.
> gpsd needs root for several things during timekeeping initialization:
>       to give itself a high priority for minimal latency timekeeping.

ntpd can do this too

>       to access KPPS
>       to access PPS on the GPS port if the port permissions are odd
>       to select and access/create the proper ntpd shmget() units
>       to select and access/create the proper chronyd socket file
> At the moment proper timekeeping initialization can only happen when
> gpsd is just started (ATM that is slightly broken).  If a device
> is hotplugged into a runing gpsd initialization of KPPS is not
> possible, the PPS device may not be accesible and the SHMs and sockets
> will be different or unavailable.

If we can find a way to better handle SHM ownership (I figure none of us
really wants to use the SHMs that are 0666) I'm happy to get that in to
the NTP codebase ASAP.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]