[gpsd-dev] (no subject)

[Harlan Stenn]

address@hidden
Fcc: +outbox
Subject: Re: [gpsd-dev] Refactor the way NTP shared memory segments are 
addressed.
In-reply-to: <address@hidden>
References: <address@hidden> <address@hidden> <address@hidden> <address@hidden> 
<address@hidden> <address@hidden> <address@hidden> <address@hidden>
Comments: In-reply-to "Gary E. Miller" <address@hidden>
   message dated "Wed, 14 Jan 2015 11:59:32 -0800."
X-Mailer: MH-E 7.4.2; nmh 1.6; XEmacs 21.4 (patch 22)
--------
Adding Juergen to the thread - I believe he did this work.
"Gary E. Miller" writes:
> Yo Harlan!
> 
> On Wed, 14 Jan 2015 08:00:12 +0000
> Harlan Stenn <address@hidden> wrote:
> 
> > "Gary E. Miller" writes:
> > > Yo Michael!
> > > 
> > > On Wed, 14 Jan 2015 10:44:14 +0400
> > > Michael Tatarinov <address@hidden> wrote:
> > > 
> > > > It's already in stable (4.2.8p1-beta3)
> > > 
> > > A beta3 is stable?  Weird...
> > 
> > It was the beta for the pending 4.2.8p1 release.
> 
> Any chance to get another tweak in first?

What do you have in mind?  There will be more patches to 4.2.8 down the road.

> > > > and new behavior is documented.
> > > 
> > > Where?
> > 
> > html/drivers/driver28.html
> 
> Did I miss the definition of the defaults?  Do segments 0 and 1 still
> default to 600 and 2 and 3 still default to 666?   If not an upgrade 
> might break existing setups.

I think so, but I haven't looked.  If they don't, then we blew a
"Backward incompatible" notice in our changelog.

> The doc seems a bit inconsistent:
> 
> "NTPD is started as root on most POSIX-like operating systems and uses
> the setuid/setgid system API to run under reduced rights once the
> initial setup of the process is done.  One consequence out of this is
> that the allocation of SHM segments must be done early during the clock
> setup."
> 
> That seems odd.  I thought the point of the change was so that the
> segment could be done after dropping root?

I agree with you and I just don't know the answer.

> > > > Now all shm segments must be perms 600.
> > > 
> > > The bug implied this was selectable in the ntp.conf?
> > 
> > "This driver receives its reference clock info from a shared
> > memory-segment. The shared memory-segment is created with owner-only
> > access by default, unless otherwise requested by the mode word for
> > units
> > >= 2. Units 0 and 1 are always created with owner-only access for
> > backward compatibility."
> 
> So this is an incompatible change?  0 and 1 no longer owned by root?

There was no explicit change that I am aware of.  Juergen might have
more to say.

> This is problematic for gpsd.  If gpsd starts first, and thus creates
> the shared segments, how is it to know the owner/perms?  Maybe gpsd
> now will always need to start after ntpd starts?  And run as the same
> user?

This has been a long-standing issue - we just don't know which process
will start first.  If this worked before it should continue to work.

> > The owner-only access segments are 0600, while the public access
> > segments are 0666.
> 
> Might it be better if the 'owner only' ran as 660?  Then gpsd
> would not need to run as the same user as ntpd, only as the same group.

I'm OK with 0660 for everybody.  But there may be cases I'm not aware of
where this would not be a good idea.

> > > Any guidance as to which user?
> > 
> > Whatever you can tell ntpd and gpsd to run as.
> 
> And when you do not that is still root?

Not sure, but Juergen should have more answers about this, if he has the
time to participate in this discussion.

> > > That means that gpsd and ntpd must run as the same user?  Many will
> > > not like that.
> > 
> > Then run with a "unit" >=2 and use a public segment.  That will
> > present other problems.  I can see somebody deciding that 0660 is a
> > good choice at some time.
> 
> Yes, but how does the present scheme allow for that?

We'd have to change that.  But 666 is ... tolerable, assuming one can
mitigate the abuse potential.

> > As an aside, we do have driver46.html now, which uses a JSON socket to
> > handle the communications between ntpd and gpsd.
> 
> Interesting.  I'll have to try that, but I am pretty sure PPS does not
> work over JSON.
> 
> I see this:
> 
> "The driver uses the error estimations (95% probability limits) provided
> by GPSD to set the clock precision dynamically according to these
> readings. "
> 
> gpsd has not sent time quality estimates in a long time since ntpd was
> not using them.  Do you instead use the DOP to guess time quality?  Not
> a good idea.

We may not be using the precision as best as we can but we do report it.
We can make better use of precision if we get discussion and/or patches.

H