[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] (no subject)
From: |
juergen perlinger |
Subject: |
Re: [gpsd-dev] (no subject) |
Date: |
Fri, 16 Jan 2015 21:00:29 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 |
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
- [gpsd-dev] (no subject), Harlan Stenn, 2015/01/14
- Re: [gpsd-dev] (no subject), Gary E. Miller, 2015/01/14
- [gpsd-dev] (no subject), Harlan Stenn, 2015/01/14
- Re: [gpsd-dev] (no subject), juergen perlinger, 2015/01/15
- Re: [gpsd-dev] (no subject), Gary E. Miller, 2015/01/15
- [gpsd-dev] (no subject), Harlan Stenn, 2015/01/15
- Re: [gpsd-dev] (no subject),
juergen perlinger <=
- Re: [gpsd-dev] (no subject), Gary E. Miller, 2015/01/16
- Re: [gpsd-dev] (no subject), juergen perlinger, 2015/01/16