> I'm worried that turning this flag on for the first time in an LTS release
> may be breaking too many expectations.
>
> Adapting applications may be too much effort; because I don't know what
> exactly apport is doing here it is hard to estimate how much effort it
> will take to adapt it. Possibly the user-launched apport instances need
> to create their own directory on launch. Possibly apport needs a
> more invasive redesign.
> [...]
> Source code searching is not practical. The combination of working
> with files in a world-writable sticky directory and not already using
> O_EXCL with O_CREAT is not feasible to search for.
FWIW, I think that the scope of the change is small enough (only in
world-writable stick directories) and dramatic enough (usually total
failure), that the risk is worth the benefit. Excepting the very few
special directories (like /var/crash, where the software using them
is likely enumerable), I would also argue that breaking stuff in
"standard" temp directories (like /tmp) that isn't using O_EXCL is
actually _desirable_, given that it is expressly risky to operate in
that condition.
And, I would suggest that doing this in an LTS is the right thing to do,
otherwise you wait 2 years before gaining this defense that would be
actively _disabled_ compared to all other distros with a modern version
of systemd. And if this is the first noticed problem, that seems to be a
reasonably good indication of how rare the case is of it creating "real"
problems.
--
Kees Cook
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
