Re: [gpsd-dev] (no subject)

[juergen perlinger]

On 01/16/2015 12:18 AM, Gary E. Miller wrote:
> Yo juergen!
>
> On Thu, 15 Jan 2015 20:52:21 +0100
> juergen perlinger <address@hidden> wrote:
>
> > Maybe I got something wrong in my understanding, but the
> > implementation should set
> Wow, not what we (gpsd-dev) were expecting.  Not obviuos from the new
> docs either.
>   
> > - SHM units 0/1 to mode 0600, owned by root
> As before.
>
> > - Other SHM units to mode 0600, owned by root  --> IF mode bit 1 is
> > cleared (default)
> > - Other SMH units to mode 0666, owned by root --> IF mode bit 1 is
> > set.
> Could we swap those?  Seems to me the this breaks compatibility with
> the old ntpd.
>
> ntpd is one of those things people just update and expect to work
> 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.

Test 1: start NTPD (-u 116:125), then start GPSD.
     remote           refid      st t when poll reach   delay offset  
jitter
==============================================================================
*127.127.46.0    .GPSD.           0 l   45   64    1    0.000 -5.149   0.000
 127.127.28.0    .SHM.            0 l   12   64    1    0.000 -490.32   
0.000
 127.127.28.1    .SHM.            0 l   11   64    1    0.000 -5.130   
0.000
 127.127.28.2    .SHM.            0 l    -   64    0    0.000 0.000   0.000

---> works <---

stopped GPSD and NTPD.
ipcrm'ed  all NTP SHM segments.

Test2: start GPSD, then start NTPD (-u 116:125).
     remote           refid      st t when poll reach   delay offset  
jitter
==============================================================================
o127.127.46.0    .GPSD.           0 l   54   64    3    0.000 -3.999  11.699
 127.127.28.0    .SHM.            0 l    5   64    3    0.000 -489.54  
24.216
 127.127.28.1    .SHM.            0 l    4   64    3    0.000 -5.913   
1.876
 127.127.28.2    .SHM.            0 l    -   64    0    0.000 0.000   0.000

---> works <---

My NTP.CONF contains

# GPSD JSON driver
server 127.127.46.0 minpoll 4 maxpoll 6
fudge  127.127.46.0 flag4 1 time2 0.51 flag3 0 flag4 1

# SHM segments
server 127.127.28.0 mode 0 noselect
server 127.127.28.1 mode 0 noselect
server 127.127.28.2 mode 1 noselect
server 127.127.28.3 mode 1 noselect

ntpq -crv tells me (amongst others)

version="ntpd address@hidden Fri Jan 16 19:21:09 UTC 2015 (1)",
processor="x86_64", system="Linux/3.16.0-29-generic", leap=00, stratum=1,

Is there something special I should be watching for?

> > There have been some cases (and IMHO it might still happen) where a
> > SHM unit can be created with the unprivileged user account. Since the
> > behavior  is not deterministic I do not like this idea. That's why I
> > tried to make sure that the SHM is always owned by root.
> Oddly many people misunderstood the change as SHM's now owned by the -u
> user, not still by root.  The doc refers to the 'user', not specifically
> to root.
>
> I have been warming to the idea that the SHM's should (optionally) be
> owned by -u user:group as perms 660.
>
> > The original (and accepted!) report claimed that having only two
> > private SHM segments was insufficient and that SHM segments should be
> > private by default unless requested otherwise.
> Yes, I see this as a step forward.  But the new implementation makes
> it so the current gpsd can no longer be started before ntpd.
Well, see above.
> > I tried to implement
> > that behavior, with an attempt to have a defined SHM owner.
> Not much point to a defined owner when the perms are 666.  If you
> are going to make an incmpatible change then many would like to see
> that defined owner not be root.
>
> > 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.
> > but I do not see anything that would require
> > changes on the side of GPSD.
> When gpsd starts first, it creates the SHM's the old way.  That would lead
> to people expecting SHMs to be perm 600 when they are actually 666.
>
> To allow gpsd to start first it will need to mimic the new behavior,
> except it has no way to determine which behavior to use.
>
> > If a different behavior is required/requested again,
> Sorry if this is old territory, but it is news to me.
>
> > I'm always open
> > to useful ideas. But there's a limit to what can be done because we
> > do not have too many configuration options: specification of a owner
> > is hardly possible with a mode word and the fudge bits.
> True, but you could use the already existing, and well used -u
> user:group.  Then the SHM code (in ntpd and gpsd) can init after
> dropping root which makes the paranoid happier.
>
> This would solve a long standing problem in gpsd. gpsd drops root early,
> but can add GPS units at any time.  After gpsd drops root it has no way
> to connect to ntpd.  Thus dynamically added GPS can not be used for SHM
> timekeeping.  If both gpsd and ntpd drop to the same group, then perms
> 660 SHM's would be easy to use.
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)

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.

> <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 ;-)

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

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

> <snip>
>
>
> 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:

     remote           refid      st t when poll reach   delay offset  
jitter
==============================================================================
o127.127.46.0    .GPSD.           0 l    2   64  377    0.000 -0.223   0.008
 127.127.28.0    .SHM.            0 l   17   64  377    0.000 -469.73  
22.732
 127.127.28.1    .SHM.            0 l   16   64  377    0.000 -0.226   
0.005
 127.127.28.2    .SHM.            0 l    -   64    0    0.000 0.000   0.000
 127.127.28.3    .SHM.            0 l    -   64    0    0.000 0.000   0.000

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