Re: [gpsd-dev] (no subject)

[juergen perlinger]

Hi Gary,

thnx for the fast reply. See below
On 01/16/2015 09:28 PM, Gary E. Miller wrote:
> Yo juergen!
>
> On Fri, 16 Jan 2015 21:00:29 +0100
> juergen perlinger <address@hidden> wrote:
>
> > > without thinking about it.  If the intent is to enforce a newer and
> > > better security model then this should at least be noted in an
> > > upgrade doc under Incompatible Changes.
> > I just tried it with the current stable version. (Which is ntpd
> > 4.2.8p1-beta5). I made sure the SHMs were 'ipcrm'd before I started.
> [...]
>
> > ---> works <---
> Yes, but...
>   
> > My NTP.CONF contains
> [...]
> > server 127.127.28.2 mode 1 noselect
>                        ^^^^^^
>
> You needed to change your ntp.conf to work.  The proper test for upward
> compatibility it to take an old ntp.conf, update to the new ntpd and
> then run your tests.  It will fail.

Nope. The units used were 0 and 1 -- the ones still owned by root, mode 
0600, as they have always been.
I guess GPSD was opening them fast/early enough.

If you insist, I'll repeat the tests with just the units 0 and 1 configured.

BTW, did I mention that I was running ntp 4.2.8-RC5? What exactly do you 
mean by 'new ntpd'? Do you know of a newer release than a build form the 
current stable BitKeeper repository? (Which should be even ahead of a 
pending tarball...)

> > > > And yes, you might have to change the SHM clock config for units
> > > > > = 2 to get the old behavior,
> > > Make that WILL.  If this stands it needs to be red flagged in the
> > > doc.
> > Accepted.
> So, we agree it is a bug.  As Linus Torvalds rants on regularly, breaking
> compatibility is unacceptable.

To quote Granny Weatherwax (just in case you read Terry Pratchett):

"Rules are not there to be followed. Rules are there to make you think 
twice before going against them."
(I'm quite sure the English original was somewhat different. I'm German 
-- I had to translate the gist of it back to English. )

I agree on breaking compatibility being a bad thing. I still don't see 
where I did so, since the configuration line you indicated is 
irrelevant: *That* slot is not used!

I refuse to accept 'a bug' as long as GPSD is able to talk to NTPD using 
the SHM slots 0 and 1, since there has been NO change to the previous 
behavior for those two clock units.

> > As a suggestion:
> >       mode bit 1: permissions o+rw
> >       mode bit 2: permissions g+rw
> >       mode bit 3: when set, owned by runtime user/group,
> >                             when cleared, owned by root.root (or maybe
> > root.wheel)
> AND no change to existing pracctive when mode is zero or empty.

A tricky point: If you enhance security, should it be mandatory or 
voluntary? I'm not going into this now. I know has the potential to be a 
breaking change, and please feel free to file a bug report against it. 
The proposal with the bug report that lead to the change seemed 
reasonable (and still does for me) and it got implemented that way. As I 
said, I'm open for ideas, but I still do not see where it breaks interop 
with GPSD.

> >       mode bit 3: when set, owned by runtime user/group,
> >                             when cleared, owned by root.root (or maybe
> > root.wheel)
> Not all Linux have wheel, so root:root.

That would be easier, too. And it's not only Linux we're talking about, 
since there are several UN*X flavors NTP targets... 'root.root' should 
be fairly universal.

> > I would still 'shmget(x,y,IPC_CREAT)' as root to open/create the
> > segment, and I might use 'shmctl()' to change the
> > owner/group/permissions as requested.
> I only care about the public interface, but that looks fair at first
> glance.
>   

It would need some testing, but IMHO it should indeed do the trick.

> > > <snip>
> > > F*ck windows. :-) Windows is already a special case, it can stay
> > > 'special'.
> > It will always be special. But Id don't think it can be ignored. The
> > UN*X world tried that approach in the 1990ies, and we still suffer
> > from it ;-)
> I'll leave that to those that care.

I do, to a certain degree.


> > > <snip>
> > > Actually, the precision is now ine as it is nanoSec possible. As
> > > for the rest I like how chronyd does it with sockets.
> > The nanosec precision is supported.
> So, we agree on the nanoSec, what about the sockets (long term)?

sockets == chrony pipes?

> > <snip>
> > > > I maintain the gpsd SHM code, does any project other than gpsd
> > > > really use the SHM code?  Let's talk.
> > Not the standard one. I cooked up something very special and it's
> > used in a SCADA system.
> Yeah, easy to forget about how the rest of the world is doing things when
> you are customizing.

I made 2 proposals on  a modified/enhanced SHM driver, and I got 
essentially NO reply. If the community is not interested (and GPSD is 
not interested in Windows) and I have a problem that needs to be solved, 
I'm going to solve it on my own. It pays my rent, my clothes and my 
cats' food. If that leads to a private customization,  then that's what 
it is.

I prefer to work WITH the community, but if pull comes to shove...

> > > BTW, ntpd should just kill off the new JSON driver, it makes
> > > assumptions that make it unuseable for timekeeping.
> > You might elaborate a bit. Because it works quite well for me:
> The gpsd PPS code runs in a its own thread.  That thread does not
> reliably report to the main thread that runs the JSON.  It could work
> on a single CPU system, but will fail strangely on multi-core systems.
> It certainly fails for me, and the first time I checked that code it was
> reporting a time value unrelated to any real PPS signal.  It looked
> great, but was imaginary.
>
> Someone patched in the link between the threads without properly locking
> things, or doing the math properly.  Since it looks like people are
> using an undocumented, untested, and known broken experimental feature
> I'll need to poke at it and make it work.

Oops. Ok, there's trouble ahead. I was reading the JSON protocol 
description (again), and I cannot find any notice for the PPS record 
being experimental. (http://www.catb.org/gpsd/gpsd_json.html, as of 
2015-01-17). BTW, I'm running on a AMD Phenom IV (64-bit quad-core), and 
it works for me. But someone might mark the PPS feature as 
'experimental' in the JSON protocol description if that's what it is. 
Please.

And since the PPS record is clearly documented, the 'undocumented' point 
is NOT taken. I might accept 'untested and known broken' once the 
documentation reflects this. It currently does NOT on the JSON protocol 
page.

But making it work would be the preferred alternative, at least in my 
universe ;-)

Greetings,
    Pearly