On Tue, Feb 25, 2020 at 6:10 PM Steve Langasek <steve.langa...@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/ > slanga...@ubuntu.com vor...@debian.org > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
