Bugzilla – Bug 1182451
Since glibc 2.33 testing for execute permission does not work
Last modified: 2023-12-01 10:04:08 UTC
When using the Tumbleweed docker image, upgrading glibc to 2.33 breaks the ability to test for execute permissions. This causes several other packages to break on install because they rely on things like sysuser-shadow which makes use of testing for execute permission. ``` allya@ponyville:~/unbounce> docker run -it opensuse/tumbleweed /bin/sh sh-5.0# touch /tmp/execute.sh sh-5.0# chmod +x /tmp/execute.sh sh-5.0# cat <<EOF >>/tmp/execute.sh > #!/bin/sh > set -eu > > ls -l "\${1:?must be provided}" > > if [ -x "\${1}" ] > then > echo 'execute ok' > else > echo 'execute not ok' > fi > EOF sh-5.0# cat /tmp/execute.sh #!/bin/sh set -eu ls -l "${1:?must be provided}" if [ -x "${1}" ] then echo 'execute ok' else echo 'execute not ok' fi sh-5.0# /tmp/execute.sh /bin/sh lrwxrwxrwx 1 root root 13 Aug 25 12:16 /bin/sh -> ../usr/bin/sh execute ok sh-5.0# zypper --non-interactive install glibc Retrieving repository 'openSUSE-Tumbleweed-Non-Oss' metadata ...........................................................................................................................................................................................................................................................[done] Building repository 'openSUSE-Tumbleweed-Non-Oss' cache ................................................................................................................................................................................................................................................................[done] Retrieving repository 'openSUSE-Tumbleweed-Oss' metadata ...............................................................................................................................................................................................................................................................[done] Building repository 'openSUSE-Tumbleweed-Oss' cache ....................................................................................................................................................................................................................................................................[done] Retrieving repository 'openSUSE-Tumbleweed-Update' metadata ............................................................................................................................................................................................................................................................[done] Building repository 'openSUSE-Tumbleweed-Update' cache .................................................................................................................................................................................................................................................................[done] Loading repository data... Reading installed packages... Resolving package dependencies... The following 2 packages are going to be upgraded: glibc glibc-locale-base The following package requires a system reboot: glibc 2 packages to upgrade. Overall download size: 4.1 MiB. Already cached: 0 B. After the operation, additional 188.6 KiB will be used. Note: System reboot required. Continue? [y/n/v/...? shows all options] (y): y Retrieving package glibc-2.33-1.1.x86_64 (1/2), 1.9 MiB ( 6.0 MiB unpacked) Retrieving: glibc-2.33-1.1.x86_64.rpm ......................................................................................................................................................................................................................................................................[done (3.8 KiB/s)] Retrieving package glibc-locale-base-2.33-1.1.x86_64 (2/2), 2.3 MiB ( 12.4 MiB unpacked) Retrieving: glibc-locale-base-2.33-1.1.x86_64.rpm ..........................................................................................................................................................................................................................................................[done (2.1 MiB/s)] Checking for file conflicts: ...........................................................................................................................................................................................................................................................................................[done] (1/2) Installing: glibc-2.33-1.1.x86_64 ................................................................................................................................................................................................................................................................................[done] (2/2) Installing: glibc-locale-base-2.33-1.1.x86_64 ....................................................................................................................................................................................................................................................................[done] Core libraries or services have been updated. Reboot is required to ensure that your system benefits from these updates. sh-5.0# /tmp/execute.sh /bin/sh lrwxrwxrwx 1 root root 13 Aug 25 12:16 /bin/sh -> ../usr/bin/sh execute not ok sh-5.0# ```
This can be validated by attempting to install `system-user-nobody` which declares a dependency on glibc 2.33 and it will fail because sysuser-shadow claims that neither groupadd or busybox are installed, which is incorrect as both are installed. > Installation of system-user-nobody-20170617-19.2.noarch failed: > Error: Subprocess failed. Error: RPM failed: ERROR: neither groupadd nor busybox found! > error: %prein(system-user-nobody-20170617-19.2.noarch) scriptlet failed, exit status 1 > error: system-user-nobody-20170617-19.2.noarch: install failed Also, testing for execution permission from the current login shell will work because it's still loaded the previous glibc, but any new login shells will fail when it loads the new glibc.
Known issue. Old versions of docker/podman (and even some newer versions if built against an older kernel AFAICT) block faccessat2 with -EPERM. See also https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/V5BMGRIN6WVWCZPENGMF74KFLHYN7KAO/ https://github.com/opencontainers/runc/pull/2750 https://github.com/seccomp/libseccomp/issues/314 So I recommend to migrate to newer versions if possible or use --security-opt seccomp:unconfined as workaround, if the extra sandboxing isn't necessary. Unfortunately there are environments where workarounds aren't easy or even possible (Travis CI, Github actions), so it would be useful if we could offer a workaround. While Arch recommends to extract a patched glibc binary on top of /, we could apply some proper (hopefully temporary) workaround in the glibc package. It might be possible to detect a broken environment by calling faccessat2 in a way which would never return -EPERM on a well behaved system (according to the man page it's actually not a valid error code at all). Reassigning to glibc maintainer.
(In reply to Fabian Vogt from comment #2) > Reassigning to glibc maintainer. ^
(In reply to Fabian Vogt from comment #3) > (In reply to Fabian Vogt from comment #2) > > Reassigning to glibc maintainer. Ah, you've assigned me -- I'm not a glibc maintainer. :D
Working as desinged.
(In reply to Andreas Schwab from comment #6) > Working as desinged. Breaking various CI workflows all over the place is surely not how glibc was designed.
Andreas, do you see any possibility to override the affected symbol(s) somehow with eg an additional shared object? Ie something that could be packaged temporarily into docker base containers while keeping glibc itself correct?
(In reply to Andreas Schwab from comment #6) > Working as desinged. Our runc packages already have the patch linked above (and have for several weeks), so it makes no sense to assign me to this issue -- I've already fixed the problem (and I wrote the original patch as well). The core issue is that GitHub (or whoever maintains the GitHub Actions infrastructure) hasn't applied this patch to their version of Docker/runc (and there is now a new Docker update pending which will include this fix). So there are two options, neither of which involve me: * Something is done with the glibc package on openSUSE to make it work with infrastructure that doesn't have the patch linked above applied. * We do nothing and wait for GitHub and others to update their infrastructure. I don't have an opinion on what is the right thing to do here, but as I said this really has nothing to do with me or the SUSE/openSUSE containers team anymore.
Not a bug.
(In reply to Andreas Schwab from comment #10) > Not a bug. The problem is that both GitHub Actions and Travis CI use Ubuntu 20.04 LTS focal and 20.10 groovy which we cannot influence. And although you don't consider it as a bug it effectively block Tumbleweed testing for various project (e.g. snapper [1], LTP [2]), thus I'd really appreciate openSUSE glibc package got patched. I understand if it results as WONTFIX due workaround being too complex/time consuming. But why pretending the problem does not exist? [1] https://github.com/openSUSE/snapper/blob/master/.github/workflows/ci-tumbleweed.yml [2] https://github.com/linux-test-project/ltp/blob/master/.travis.yml
Also whole yast testing done by github actions are affected and we as workaround start using Leap 15.3 docker image, so there is bigger chance that some changes in TW that breaks yast is caught too late. So maybe it is not bug, but result is that TW docker image is basically useless ( and not just docker, but e.g. also WSL is affected ).
Tell Microsoft then.
... and Travis, and .... Yes, although this is not our bug by definition it makes a lot of troubles outside in the community. As commented above, if you are an upstream developer and want to run your CI using Travis or GitHub Actions then you are doomed. A big issue is that the problem is not obvious, you can get strange permission errors or missing file errors. I spent quite some time with debugging, then I realized that the problem is not in our code or setup. And as you cannot fix it by yourselves the only solution is to ignore the CI failures on TW or even completely disable it. That will definitely not create a good impression in the OSS community... :-( So IMHO we should try to workaround the problem at least until the major services which use Docker (GitHub, Travis,...) fully support the new glibc.
Does anybody know what would be a correct fix in our glibc?
Or should we bring the discussion to glibc upstream?
(In reply to Petr Vorel from comment #15) > Does anybody know what would be a correct fix in our glibc? Unfortunately a real "fix" isn't possible, at best a workaround. The issue is that the seccomp profile in between glibc and the kernel behaves like a "wrong" kernel, in such a way that this error is indistinguishable from an actual "Permission denied". So glibc either has to avoid using faccessat2 completely, fall back to the old code in case of -EPERM, or actively probe for the presence of this issue by doing something like I suggested in comment 2, for instance faccessat2(-2, ".", 0, 0) which returns -EPERM with this bug but -EBADFD or -ENOSYS without. (In reply to Petr Vorel from comment #16) > Or should we bring the discussion to glibc upstream? Ideally yes, as this also affects other distros. Arch for instance ran into this a few days before we did. Alpine (Musl instad of glibc) is similarly affected. So we're not the only ones, but we can adjust our software.
(In reply to Fabian Vogt from comment #17) > So glibc either has to avoid using faccessat2 completely, fall back to the > old code in case of -EPERM, or actively probe for the presence of this issue > by doing something like I suggested in comment 2, for instance > faccessat2(-2, ".", 0, 0) which returns -EPERM with this bug but -EBADFD or > -ENOSYS without. Thanks, that could work! I'll try to have look into it. > (In reply to Petr Vorel from comment #16) > > Or should we bring the discussion to glibc upstream? > > Ideally yes, as this also affects other distros. Arch for instance ran into > this a few days before we did. And obviously Fedora rawhide as well. > Alpine (Musl instad of glibc) is similarly affected. Interesting, didn't know musl is also affected.
(In reply to Petr Vorel from comment #18) > (In reply to Fabian Vogt from comment #17) > > So glibc either has to avoid using faccessat2 completely, fall back to the > > old code in case of -EPERM, or actively probe for the presence of this issue > > by doing something like I suggested in comment 2, for instance > > faccessat2(-2, ".", 0, 0) which returns -EPERM with this bug but -EBADFD or > > -ENOSYS without. > > Thanks, that could work! I'll try to have look into it. > > > (In reply to Petr Vorel from comment #16) > > > Or should we bring the discussion to glibc upstream? > > > > Ideally yes, as this also affects other distros. Arch for instance ran into > > this a few days before we did. > And obviously Fedora rawhide as well. > > > Alpine (Musl instad of glibc) is similarly affected. > Interesting, didn't know musl is also affected. _Everyone_ that uses any new syscall and uses the usual fallback code to cater for old kernels without it will be affected. faccessat2 usage in glibc 2.33 is just the most recent example, there were more instances over the past years. It can really only be solved by fixing the bug in Dockers seccomp usage (and everywhere that seemingly copied thinking along the lines of "oh it's security, I guess EPERM is a good return code"). I appreciate that you have real and hard problems with CI chains, but you need to complain loudly to providers of them. While the work-around suggested by Fabian might work, I'm not overly thrilled. It might merely delay the real bugfix at seccomp side. It would probably be better to downgrade glibc temporarily in the projects where you need that (not in TW, mind you).
(In reply to Michael Matz from comment #19) > (In reply to Petr Vorel from comment #18) > > (In reply to Fabian Vogt from comment #17) > > > So glibc either has to avoid using faccessat2 completely, fall back to the > > > old code in case of -EPERM, or actively probe for the presence of this issue > > > by doing something like I suggested in comment 2, for instance > > > faccessat2(-2, ".", 0, 0) which returns -EPERM with this bug but -EBADFD or > > > -ENOSYS without. > > > > Thanks, that could work! I'll try to have look into it. > > > > > (In reply to Petr Vorel from comment #16) > > > > Or should we bring the discussion to glibc upstream? > > > > > > Ideally yes, as this also affects other distros. Arch for instance ran into > > > this a few days before we did. > > And obviously Fedora rawhide as well. > > > > > Alpine (Musl instad of glibc) is similarly affected. > > Interesting, didn't know musl is also affected. > > _Everyone_ that uses any new syscall and uses the usual fallback code to > cater > for old kernels without it will be affected. faccessat2 usage in glibc > 2.33 is just the most recent example, there were more instances over the past > years. I remember statx well - it broke most prominently with Qt on Ubuntu 18.04. I suppose the time64 calls on 32bit archs were/are also affected, but apparently those aren't popular in CIs. > It can really only be solved by fixing the bug in Dockers seccomp > usage Yes, that was a broken design, but the story is a bit longer - libseccomp didn't make it possible (at least not easily) to implement it properly (e.g. returning -ENOSYS for unknown syscalls). This is fixed meanwhile, at least in runc: https://github.com/opencontainers/runc/pull/2750 So that is now dealt with in a hopefully future-proof way. > (and everywhere that seemingly copied thinking along the lines of "oh it's > security, I guess EPERM is a good return code"). At least a whilelist of syscalls is better than a blacklist, for security purposes... Chromium for instance handles it differently, by killing the process with a SIGSYS if a syscall is unknown. Fortunately that's relatively easy to spot and address. > I appreciate that you have real and hard problems with CI chains, but you > need > to complain loudly to providers of them. While the work-around suggested by > Fabian might work, I'm not overly thrilled. It might merely delay the real > bugfix at seccomp side. It's already broken now and they don't seem to care too much about non-Ubuntu. It's a free (as in beer) service, so that's their right. From the user perspective it's clear: Tumbleweed in the CI doesn't work, so they have to switch to something else. We're losing users and CI coverage because of this. Ubuntu and other distros which aren't affected (yet) don't. The good news is that we're entirely capable to address this issue on our own, by applying a workaround in glibc. > It would probably be better to downgrade glibc > temporarily in the projects where you need that (not in TW, mind you). This isn't possible: TW needs glibc 2.33 so you'd have to rebuild everything against the old version. Even in TW itself, a downgrade isn't easily possible. Introducing a "glibc-nofaccessat2" package would work, but that's IMO even worse than a workaround in the glibc package directly.
(In reply to Fabian Vogt from comment #20) > From the user perspective it's clear: Tumbleweed in the CI doesn't work, so > they have to switch to something else. We're losing users and CI coverage > because of this. Ubuntu and other distros which aren't affected (yet) don't. Yes, that's my point. Personally I hate any hacks or workarounds in code, but if it is really needed then OK. In this case the workaround would be just temporary, after the major CI services upgrade the Docker environment we could remove that.
(In reply to Michael Matz from comment #19) > I appreciate that you have real and hard problems with CI chains, but you > need > to complain loudly to providers of them. While the work-around suggested by > Fabian might work, I'm not overly thrilled. It might merely delay the real > bugfix at seccomp side. It would probably be better to downgrade glibc > temporarily in the projects where you need that (not in TW, mind you). Even if it were possible to downgrade (that's not as Fabian noted in comment #20) for CI it's important to use glibc currently used in OS, not for older one. (In reply to Ladislav Slezák from comment #21) > (In reply to Fabian Vogt from comment #20) > > From the user perspective it's clear: Tumbleweed in the CI doesn't work, so > > they have to switch to something else. We're losing users and CI coverage > > because of this. Ubuntu and other distros which aren't affected (yet) don't. +1 > Yes, that's my point. Personally I hate any hacks or workarounds in code, > but if it is really needed then OK. In this case the workaround would be > just temporary, after the major CI services upgrade the Docker environment > we could remove that. +1
RFC patch sent to upstream https://sourceware.org/pipermail/libc-alpha/2021-February/123004.html http://patchwork.ozlabs.org/project/glibc/patch/20210225194702.6113-1-pvorel@suse.cz/
OK, I missed the previous discussion on this subject [1][2]. Given that both upstream and Andreas (our maintainer) are against it, we probably just have to live with the fact Tumbleweed container does not run on host with an old environment. [1] https://sourceware.org/pipermail/libc-alpha/2020-November/119955.html [2] https://lore.kernel.org/linux-api/87lfer2c0b.fsf@oldenburg2.str.redhat.com/T/#u
*** Bug 1182655 has been marked as a duplicate of this bug. ***
This appears fixed with the latest Tumbleweed from Docker Hub. For posterity: what happened?
(In reply to Michal Nowak from comment #26) > This appears fixed with the latest Tumbleweed from Docker Hub. For > posterity: what happened? IMHO nothing has changed on our side [1]. It looks like Github fixed their docker setup, because job on Github Actions which previously failed is now working [2]. But Travis CI is still not working with the default setup [3]. I also tested it locally with podman with the default runtime (crun). Workaround is e.g. running podman with updated runc [4] [5] (using docker with updated runc does not work). And noth Travis CI and Github are using 20.04 LTS focal. [1] https://build.opensuse.org/package/view_file/Base:System/glibc/glibc.changes?expand=1 [2] https://github.com/pevik/snapper/actions/workflows/ci-tumbleweed.yml [3] https://travis-ci.org/github/pevik/ltp/builds/761914869 [4] https://github.com/linux-test-project/ltp/commit/6563f1733b6e1beb7a9c6a84b8a66043d7a47e8e [5] https://travis-ci.org/github/linux-test-project/ltp/jobs/761107469
I'm hitting this issue when trying to build TW containers with podman on SLE15 SP2. Updating glibc isn't really an option there. --security-opt=seccomp:unconfined for podman doesn't workaround the issue either.
(In reply to Frederic Crozat from comment #28) > I'm hitting this issue when trying to build TW containers with podman on > SLE15 SP2. Updating glibc isn't really an option there. (And wouldn't help, it's the outside seccomp implementation that's buggy and causes problems with the inside 2.33 glibc. The outside glibc doesn't enter the picture). > --security-opt=seccomp:unconfined for podman doesn't workaround the issue > either. Google and http://docs.podman.io/en/latest/markdown/podman-run.1.html tells me it's –security-opt=seccomp=unconfined for podman.
(In reply to Michael Matz from comment #29) > (In reply to Frederic Crozat from comment #28) > > I'm hitting this issue when trying to build TW containers with podman on > > SLE15 SP2. Updating glibc isn't really an option there. > > (And wouldn't help, it's the outside seccomp implementation that's buggy and > causes problems with the inside 2.33 glibc. The outside glibc doesn't enter > the > picture). > > > --security-opt=seccomp:unconfined for podman doesn't workaround the issue > > either. > > Google and http://docs.podman.io/en/latest/markdown/podman-run.1.html tells > me > it's –security-opt=seccomp=unconfined for podman. unfortunately --security-opt=seccomp=unconfined (which is the proper syntax) works with "podman run" but doesn't do anything with "podman build" :(
(In reply to Frederic Crozat from comment #30) > > Google and http://docs.podman.io/en/latest/markdown/podman-run.1.html tells > > me > > it's –security-opt=seccomp=unconfined for podman. > > unfortunately --security-opt=seccomp=unconfined (which is the proper syntax) > works with "podman run" but doesn't do anything with "podman build" :( I see. According to http://docs.podman.io/en/latest/markdown/podman-build.1.html I read that the seccomp option is supposed to be supported with 'build', so I'd consider this another podman bug.
(In reply to Michael Matz from comment #31) > (In reply to Frederic Crozat from comment #30) > > > Google and http://docs.podman.io/en/latest/markdown/podman-run.1.html tells > > > me > > > it's –security-opt=seccomp=unconfined for podman. > > > > unfortunately --security-opt=seccomp=unconfined (which is the proper syntax) > > works with "podman run" but doesn't do anything with "podman build" :( > > I see. According to > http://docs.podman.io/en/latest/markdown/podman-build.1.html > I read that the seccomp option is supposed to be supported with 'build', so > I'd > consider this another podman bug. I just tried to update podman on SLE15 SP2 to version 3.0.2 => no change. However, updating runc to version v1.0.0~rc93 (with podman 2.1.1 from SLE15 SP2) fixed the issue completely. Aleksa, should I open a SLE15 SP2 bug to get runc either updated or at least, with the seccomp fix backported ?
(In reply to Frederic Crozat from comment #32) > I just tried to update podman on SLE15 SP2 to version 3.0.2 => no change. > > However, updating runc to version v1.0.0~rc93 (with podman 2.1.1 from SLE15 > SP2) fixed the issue completely. Yes, yes only new runc is needed. It'd be nice if we documented it somewhere on openSUSE wiki (to provide docs when host distro is not openSUSE). > Aleksa, should I open a SLE15 SP2 bug to get runc either updated or at > least, with the seccomp fix backported ? +1
(In reply to Frederic Crozat from comment #32) > (In reply to Michael Matz from comment #31) > > (In reply to Frederic Crozat from comment #30) > > > > Google and http://docs.podman.io/en/latest/markdown/podman-run.1.html tells > > > > me > > > > it's –security-opt=seccomp=unconfined for podman. > > > > > > unfortunately --security-opt=seccomp=unconfined (which is the proper syntax) > > > works with "podman run" but doesn't do anything with "podman build" :( > > > > I see. According to > > http://docs.podman.io/en/latest/markdown/podman-build.1.html > > I read that the seccomp option is supposed to be supported with 'build', so > > I'd > > consider this another podman bug. > > I just tried to update podman on SLE15 SP2 to version 3.0.2 => no change. > > However, updating runc to version v1.0.0~rc93 (with podman 2.1.1 from SLE15 > SP2) fixed the issue completely. > > Aleksa, should I open a SLE15 SP2 bug to get runc either updated or at > least, with the seccomp fix backported ? No response, which I'd say means "yes" in this case.
related issues: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1916485 https://bugs.archlinux.org/task/69563 https://github.com/seccomp/libseccomp/issues/286 https://bugzilla.redhat.com/show_bug.cgi?id=1900021 I guess, it could help us if we helped Ubuntu get a fixed docker/runc
More reports about this are still incoming: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/JMQZW6TJB3SAOLEU6NYJHKLA3HAB2FSY/ (In reply to Bernhard Wiedemann from comment #35) > related issues: > > https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1916485 > https://bugs.archlinux.org/task/69563 > https://github.com/seccomp/libseccomp/issues/286 > https://bugzilla.redhat.com/show_bug.cgi?id=1900021 > > I guess, it could help us if we helped Ubuntu get a fixed docker/runc Would also be nice to get SLE fixed. Aleksa is in NEEDINFO for this.
(In reply to Fabian Vogt from comment #36) > More reports about this are still incoming: > https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/ > JMQZW6TJB3SAOLEU6NYJHKLA3HAB2FSY/ > > (In reply to Bernhard Wiedemann from comment #35) > > related issues: > > > > https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1916485 > > https://bugs.archlinux.org/task/69563 > > https://github.com/seccomp/libseccomp/issues/286 > > https://bugzilla.redhat.com/show_bug.cgi?id=1900021 > > > > I guess, it could help us if we helped Ubuntu get a fixed docker/runc > > Would also be nice to get SLE fixed. Aleksa is in NEEDINFO for this. Yes, I will submit things to SLE. The main complication is that docker-runc no longer exists in Factory (but still exists in SLES) so I would like to also update Docker in tandem and I wasn't quite sure who I needed to contact to get that done. (The new runc package obsoletes docker-runc, which is the main issue. I could cook up a custom package just for now but that will cause some minor packaging headaches down the road when I next submit directly from Factory.)
If at least some people have accepted that this can be fixed in SLE can we please regard the bug as not resolved then? As the original maintainer does not want to contribute more than three-word answers ;) , asarai@suse.com is it ok if you are the assignee as you stated that you could submit something? I came across this issue as I have ran into this myself as well as we have hit it in our CI environments for SUSE QE Tools development, e.g. openQA.
(In reply to Aleksa Sarai from comment #37) > (In reply to Fabian Vogt from comment #36) > > More reports about this are still incoming: > > https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/ > > JMQZW6TJB3SAOLEU6NYJHKLA3HAB2FSY/ > > > > (In reply to Bernhard Wiedemann from comment #35) > > > related issues: > > > > > > https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1916485 > > > https://bugs.archlinux.org/task/69563 > > > https://github.com/seccomp/libseccomp/issues/286 > > > https://bugzilla.redhat.com/show_bug.cgi?id=1900021 > > > > > > I guess, it could help us if we helped Ubuntu get a fixed docker/runc > > > > Would also be nice to get SLE fixed. Aleksa is in NEEDINFO for this. > > Yes, I will submit things to SLE. The main complication is that docker-runc > no longer exists in Factory (but still exists in SLES) so I would like to > also update Docker in tandem and I wasn't quite sure who I needed to contact > to get that done. (The new runc package obsoletes docker-runc, which is the > main issue. I could cook up a custom package just for now but that will > cause some minor packaging headaches down the road when I next submit > directly from Factory.) Apparently runc is already part of the containers module, so just submitting it should actually be enough. Or is there some other issue? There's meanwhile also a report specifically for podman on SLE: https://bugzilla.suse.com/show_bug.cgi?id=1184962 (In reply to Oliver Kurz from comment #38) > If at least some people have accepted that this can be fixed in SLE can we > please regard the bug as not resolved then? As the original maintainer does > not want to contribute more than three-word answers ;) , asarai@suse.com is > it ok if you are the assignee as you stated that you could submit something? > > I came across this issue as I have ran into this myself as well as we have > hit it in our CI environments for SUSE QE Tools development, e.g. openQA. What's the CI environment running as OS and container runtime?
> (In reply to Oliver Kurz from comment #38) > > If at least some people have accepted that this can be fixed in SLE can we > > please regard the bug as not resolved then? As the original maintainer does > > not want to contribute more than three-word answers ;) , asarai@suse.com is > > it ok if you are the assignee as you stated that you could submit something? > > > > I came across this issue as I have ran into this myself as well as we have > > hit it in our CI environments for SUSE QE Tools development, e.g. openQA. > > What's the CI environment running as OS and container runtime? for me right now that would be openSUSE Leap 15.2 x86_64 using podman 2.2.1 from official Leap repos trying to run a Tumbleweed container image
(In reply to Fabian Vogt from comment #39) > (In reply to Aleksa Sarai from comment #37) > > Yes, I will submit things to SLE. The main complication is that docker-runc > > no longer exists in Factory (but still exists in SLES) so I would like to > > also update Docker in tandem and I wasn't quite sure who I needed to contact > > to get that done. (The new runc package obsoletes docker-runc, which is the > > main issue. I could cook up a custom package just for now but that will > > cause some minor packaging headaches down the road when I next submit > > directly from Factory.) > > Apparently runc is already part of the containers module, so just submitting > it should actually be enough. Or is there some other issue? Ah, right. For some reason I thought they were build-only and weren't shipped. Yeah it's probably fine to submit things now and we can drop the old packages (docker-runc, golang-github-docker-libnetwork) separately.
(In reply to Oliver Kurz from comment #38) > If at least some people have accepted that this can be fixed in SLE can we > please regard the bug as not resolved then? As the original maintainer does > not want to contribute more than three-word answers ;) , asarai@suse.com is > it ok if you are the assignee as you stated that you could submit something? I'm submitting the updated runc version, which will solve this problem if you have a Leap or SLES host (sorry it took a while to do this), but this won't help if you're running any other host and a Tumbleweed container.
(Another concern with updating docker was a libnetwork regression that I still haven't been able to figure out, which caused Docker to fail to start on SLES and Leap when running with firewalld. It is possible it was caused by a bad backport but I'm not sure.)
SUSE-SU-2021:1458-1: An update that solves 9 vulnerabilities and has 23 fixes is now available. Category: security (important) Bug References: 1028638,1034053,1048046,1051429,1053532,1095817,1118897,1118898,1118899,1121967,1131314,1131553,1149954,1152308,1160452,1168481,1175081,1175821,1181594,1181641,1181677,1181730,1181732,1181749,1182451,1182476,1182947,1183024,1183397,1183855,1184768,1184962 CVE References: CVE-2018-16873,CVE-2018-16874,CVE-2018-16875,CVE-2019-16884,CVE-2019-19921,CVE-2019-5736,CVE-2021-21284,CVE-2021-21285,CVE-2021-21334 JIRA References: Sources used: SUSE Linux Enterprise Module for Containers 12 (src): containerd-1.4.4-16.38.1, docker-20.10.6_ce-98.66.1, runc-1.0.0~rc93-16.8.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
*** Bug 1185767 has been marked as a duplicate of this bug. ***
SUSE-SU-2021:1954-1: An update that solves four vulnerabilities and has 13 fixes is now available. Category: security (important) Bug References: 1168481,1175081,1175821,1181594,1181641,1181677,1181730,1181732,1181749,1182451,1182476,1182947,1183024,1183855,1184768,1184962,1185405 CVE References: CVE-2021-21284,CVE-2021-21285,CVE-2021-21334,CVE-2021-30465 JIRA References: Sources used: SUSE MicroOS 5.0 (src): containerd-1.4.4-5.32.1, docker-20.10.6_ce-6.49.3, runc-1.0.0~rc93-1.14.2 SUSE Manager Server 4.0 (src): containerd-1.4.4-5.32.1, docker-20.10.6_ce-6.49.3, runc-1.0.0~rc93-1.14.2 SUSE Manager Retail Branch Server 4.0 (src): containerd-1.4.4-5.32.1, docker-20.10.6_ce-6.49.3, runc-1.0.0~rc93-1.14.2 SUSE Manager Proxy 4.0 (src): containerd-1.4.4-5.32.1, docker-20.10.6_ce-6.49.3, runc-1.0.0~rc93-1.14.2 SUSE Linux Enterprise Server for SAP 15-SP1 (src): containerd-1.4.4-5.32.1, docker-20.10.6_ce-6.49.3, runc-1.0.0~rc93-1.14.2 SUSE Linux Enterprise Server for SAP 15 (src): containerd-1.4.4-5.32.1, docker-20.10.6_ce-6.49.3, runc-1.0.0~rc93-1.14.2 SUSE Linux Enterprise Server 15-SP1-LTSS (src): containerd-1.4.4-5.32.1, docker-20.10.6_ce-6.49.3, runc-1.0.0~rc93-1.14.2 SUSE Linux Enterprise Server 15-SP1-BCL (src): containerd-1.4.4-5.32.1, docker-20.10.6_ce-6.49.3, runc-1.0.0~rc93-1.14.2 SUSE Linux Enterprise Server 15-LTSS (src): containerd-1.4.4-5.32.1, docker-20.10.6_ce-6.49.3, runc-1.0.0~rc93-1.14.2 SUSE Linux Enterprise Module for Containers 15-SP3 (src): containerd-1.4.4-5.32.1, docker-20.10.6_ce-6.49.3, runc-1.0.0~rc93-1.14.2 SUSE Linux Enterprise Module for Containers 15-SP2 (src): containerd-1.4.4-5.32.1, docker-20.10.6_ce-6.49.3, runc-1.0.0~rc93-1.14.2 SUSE Linux Enterprise High Performance Computing 15-SP1-LTSS (src): containerd-1.4.4-5.32.1, docker-20.10.6_ce-6.49.3, runc-1.0.0~rc93-1.14.2 SUSE Linux Enterprise High Performance Computing 15-SP1-ESPOS (src): containerd-1.4.4-5.32.1, docker-20.10.6_ce-6.49.3, runc-1.0.0~rc93-1.14.2 SUSE Linux Enterprise High Performance Computing 15-LTSS (src): containerd-1.4.4-5.32.1, docker-20.10.6_ce-6.49.3, runc-1.0.0~rc93-1.14.2 SUSE Linux Enterprise High Performance Computing 15-ESPOS (src): containerd-1.4.4-5.32.1, docker-20.10.6_ce-6.49.3 SUSE Enterprise Storage 7 (src): runc-1.0.0~rc93-1.14.2 SUSE Enterprise Storage 6 (src): containerd-1.4.4-5.32.1, docker-20.10.6_ce-6.49.3, runc-1.0.0~rc93-1.14.2 SUSE CaaS Platform 4.0 (src): containerd-1.4.4-5.32.1, docker-20.10.6_ce-6.49.3, runc-1.0.0~rc93-1.14.2 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
openSUSE-SU-2021:0878-1: An update that solves four vulnerabilities and has 13 fixes is now available. Category: security (important) Bug References: 1168481,1175081,1175821,1181594,1181641,1181677,1181730,1181732,1181749,1182451,1182476,1182947,1183024,1183855,1184768,1184962,1185405 CVE References: CVE-2021-21284,CVE-2021-21285,CVE-2021-21334,CVE-2021-30465 JIRA References: Sources used: openSUSE Leap 15.2 (src): containerd-1.4.4-lp152.2.6.1, docker-20.10.6_ce-lp152.2.12.1, runc-1.0.0~rc93-lp152.2.3.1
*** Bug 1183351 has been marked as a duplicate of this bug. ***
*** Bug 1187588 has been marked as a duplicate of this bug. ***
openSUSE-SU-2021:1954-1: An update that solves four vulnerabilities and has 13 fixes is now available. Category: security (important) Bug References: 1168481,1175081,1175821,1181594,1181641,1181677,1181730,1181732,1181749,1182451,1182476,1182947,1183024,1183855,1184768,1184962,1185405 CVE References: CVE-2021-21284,CVE-2021-21285,CVE-2021-21334,CVE-2021-30465 JIRA References: Sources used: openSUSE Leap 15.3 (src): containerd-1.4.4-5.32.1, docker-20.10.6_ce-6.49.3, runc-1.0.0~rc93-1.14.2
Is there anything left to do for this bug? I assume it has been fixed for a while now.
Closing as fixed.