apport permission error

[Christian Ehrhardt]

On Tue, Feb 25, 2020 at 6:10 PM Steve Langasek <steve.langasek at ubuntu.com>
wrote:

> On Tue, Feb 25, 2020 at 02:04:51PM +1030, Alex Murray wrote:
> > > 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?
>
> > (I'll let Kees respond for himself but figured this was a good point to
> > reply)
>
> > From the Ubuntu Security team's view, it is not clear how much breakage
> > will result from setting this to 2 - setting protected_regular=1 is
> > already a good win and so far has seen little fallout that I know of
> > (Apport has already worked around this), but given how close we are to
> > FF I am a bit hesitant to mandate for this to be =2 (given we
> > already have one known failure as a result). From a security point of
> > view, =2 is a better default but this is not the only view that
> > matters.
>
> > So my preference would be to keep this at =2 for now but be confident
> > that we can back it out to =1 in the event that we suddenly discover a
> > bunch more issues in the near term.
>
> Thanks, it's easy enough to back out later (as long as someone actually
> raises a flag when things break!), so I'm ok with that.
>
> Since postgresql-common's tests have now been fixed for compatibility with
> =2, the procps with this new behavior will be unblocked and should reach
> the
> focal release today or tomorrow.
>

I think it won't migrate as-is.
Since this was out-of order compared to Debian there are a few
no-change-rebuilds needed.
Update_output suggests we are stuck on the rev-deps to the old lib version:

$ reverse-depends -r focal libprocps7
Reverse-Depends
===============
* apitrace [amd64 arm64 armhf ppc64el s390x]
* cpu-x [amd64]
* deepin-screen-recorder [amd64 arm64 armhf ppc64el s390x]
* intel-gpu-tools [amd64 i386]
* libprocps-dev
* procps
* veyon-plugins [amd64 arm64 armhf ppc64el s390x]


-- 
> 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 at ubuntu.com                                     vorlon at debian.org
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>


-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20200226/7c640eb4/attachment-0001.html>