Re: [gpsd-dev] Updated docs on NTP segment management

[Hal Murray]

>> We can replace it with a new scheme that is read only to clients.
> Yes, there are cool new things to do, but ntpshm is very lightweight, thus
> embedded friendly.  Plus, I assume, a large legacy usage. 

Is there a problem (bug?) you are trying to fix?


> An interesting idea.  You are suggesting perms 640 or 644?  If ntpd runs as
> ntpd:ntpd and creates the ntpshm as 640, then how does gpsd which runs as
> gpsd:ntpd write to it?

I was thinking of 644, owned and created by gpsd.

> I would hate to enforce that ntpd never create the ntpshm, or that ntpd and
> gpsd run as the same user. 

What's the problem with created by gpsd (and not ntpd)?


>> Is there any reason to make gpsd's SHM not world readable?
> Not that I can think of, but worth asking around.  Seems to me local time is
> not exactly a secret. 

If it is a problem, we can shift to 640 and require clients to be in the same 
group.

But that requires setting up a new group, so I propose 644 until we find a 
need.

If the location was in there, that might be worth hiding.  Does anybody 
disable the JSON interface?


-- 
These are my opinions.  I hate spam.