Monday 24 February 2020

Re: apport permission error

On Fri, Feb 21, 2020 at 02:04:37PM -0800, Kees Cook wrote:
> On Thu, Feb 20, 2020 at 03:45:39AM +0000, Seth Arnold wrote:
> > 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.

As an additional wrinkle, procps in focal-proposed is now setting
fs.protected_regular=2 by default, overriding the systemd setting. This
hasn't made it out of proposed yet because the additional restriction broke
the postgresql-common autopkgtest (fix for this is in progress):
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1864423

Kees, it sounds like you were advocating for setting the level to
fs.protected_regular=1, but NOT raising it to 2. Should we back out this
procps change for 20.04?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org