Yo Harlan!
On Wed, 14 Jan 2015 22:45:17 +0000
Harlan Stenn <address@hidden> wrote:
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.
See below.
Looking at the 4.2.8 release code, I see it is still the old way:
shmid=shmget (0x4e545030 + unit, sizeof (struct shmTime),
IPC_CREAT | ((unit < 2) ? 0600 : 0666));
Where can I get the code with the new way?
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.
Seems to me, that right now, most distros start ntpd as root, create
SHMs 0 and 1 as root, then drop to user ntpd or daemon.
If I understand the new code (not saying I do) then SHMs 0 and 1 will be
created perms 600 as the setuid user (ntpd or daemon).
If that is true, then two cases:
If gpsd starts first, and creates 0 and 1 as 600 for root, then
ntpd can not access them.
If ntpd starts first, then I presume that gpsd, as root, still can
access 0 and 1.
So, if I got the first case right, that would break my current setup.
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.
My guess is the doc has not been updated to the new code. It makes a
lot of sense, and would fix some existing brooken cases, for the SHMs
to have permissions it can work with after the setuid(). This has been
a problem for gpsd as reconfiguration can not take place after dropping
root.
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.
Yeah, a pointer to the code changes would help.
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.
Well, it has been problematic. I would like to see the SHMs as 660.
That way gpsd and ntpd can (more) initialize and configure as non-root,
and not as the same user. gpsd and ntpd could both be in the ntpd
group and happily reconfigure interfaces while runnning while maintaining
minimal permissions.
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.
When in doubt, make it an option (mode). :-) It has to be better than
600/root or 666.
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.
Some clarity over the code change would be good.
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.
I could drop a few names of people that would violently disagree. Being
able to change system time should not be possible for any and all users.
Often the first thing a hacker does is chnage the system time so he can
change system files without changing the ctime. Time is a critical
security item.
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.
gpsd has not reported a meaningful time precision for years. It was
a floating point calculation and the embedded guys wanted to lose
the floating point. When it was verified ntpd did not use the gpsd
provided precision it was removed. ntpd was reporting a precision it
wass internally calculating. Last I checked that calculation looked
valid, so best left as it is, just needs documentation.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
address@hidden Tel:+1(541)382-8588