On 12/19/2017 01:42 PM, Hal Murray via devel wrote:
> My notes in ntpd.c at ENABLE_EARLY_DROPROOT say it doesn't work with SHM or
> NetBSD. Can we fix the SHM stuff? I've long been scheming on making the
> ntpd side of SHM read-only but that won't be a quick fix.
> Richard: Have you tried earl
> The question by Richard still stands, though: we should not do anything as
> root that can be done with lesser privileges, so why not defer reading the
> drift file until after we've dropped root? That would be vastly preferrable
> to any of the other workarounds discussed.
The original idea
Hal Murray via devel writes:
> I'm not following what you are trying to describe.
>
> If a bad guy can set things up so the write to a file does something nasty,
> can't they just do the nasty stuff directly?
The point is that they can sometimes do even more nasty things,
privilege escalation so
> That's not a fix, that's creating a latent security problem with clobbering
> a file name that's known in advance so you can plant things under that name
> and have it overwrite a different file that you normally wouldn't be able to
> access.
I'm not following what you are trying to describe.
Hal Murray via devel writes:
> I just pushed a fix for Issue #409. The drift file now gets created with the
> normal protection modes rather than 600 so apparmor should be happy when
> reading it as root during startup. (Unless you have a non-standard default
> mode. ...)
That
I just pushed a fix for Issue #409. The drift file now gets created with the
normal protection modes rather than 600 so apparmor should be happy when
reading it as root during startup. (Unless you have a non-standard default
mode. ...)
I also added a few more uses of uptime_t and removed
