Re: [gpsd-dev] (no subject)

[Gary E. Miller]

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.

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

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

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

> Not to
> mention that the rights/access/ownership management is quite
> differently handled between POSIX systems and Windows.

F*ck windows.  :-)  Windows is already a special case, it can stay 
'special'.

> As for the other issues regarding the ancilliary data (precision, 
> suggested poll, leap indication, ...): The current handling of the
> SHM is outdated.

Actually, the precision is now ine as it is nanoSec possible.  As for
the rest I like how chronyd does it with sockets.

> Modern hardware needs other methods and access
> patterns for a reliable communication via SHM.  There's also a bug
> pending for a more versatile SHM driver, but it looks to me that
> no-one is really interested in talking about  it :(

I maintain the gpsd SHM code, does any project other than gpsd really
use the SHM code?  Let's talk.

> And maybe it would be better to use some form of message passing,
> using message queues or pipes or whatever, because then the whole
> access synchronization mess would be handled by the OS and not by
> NTPD and the client application.  Just my thoughts, though.

As I said, I like the chronyd sockets if we are to add, but we are stuck
with a lot of legacy installations.  Let's add cool new stuff, but avoid
non-obvious incompatible changes.

BTW, ntpd should just kill off the new JSON driver, it makes assumptions
that make it unuseable for timekeeping.

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