Re: ✘64-bit time_t on glibc 2.34 and up

[Miroslav Lichvar]

On Thu, Jan 12, 2023 at 05:10:13PM -0800, Gary E. Miller wrote:
> 4.  gpsd and ntpd always use 64-bit time_t going forward.  Admin needs
> to mix and match.

I suspect that wouldn't work, at least generally. It would prevent
gpsd/ntpd from using a library which has time_t in its API, e.g.
I see timevals in libusb.h. 

I think it is expected to be a distro policy to select which time_t is
used in all applications and have that -D_TIME_BITS=64 in some global
CPPFLAGS/CFLAGS followed by all packages. gpsd could make it easier
for users compiling it themselves and check some known locations of
these global flags.

> 5.  1st process to open SHM(0) wins, the other process checks the size
> to know the contents.

This one makes most sense to me, if you feel you need to support both
at the same time.

Instead of complicating the SHM support, I'd prefer if you deprecated
it in favor of the SOCK or something else to avoid the security issue
with untrusted applications creating the SHM segment before
gpsd/ntpd/chronyd.

> Also note, chrony sockets have a similar problem:
> 
> #define SOCK_MAGIC 0x534f434b
> struct sock_sample {
>     struct timeval tv;
>     double offset;
>     int pulse;
>     int leap;       // notify that a leap second is upcoming
>     int _pad;
>     int magic;      // must be SOCK_MAGIC
> };

It could check the length of the message, see if the magic value
at the end is correct, and convert the message to the expected time_t
if it doesn't match the one that was used in compilation.

-- 
Miroslav Lichvar