[gpsd-dev] (no subject)

[Harlan Stenn]

Juergen,

Any thoughts?

H
--
"Gary E. Miller" writes:
> 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
>