Le lun. 27 sept. 2021 à 16:08, Reinhard Tartler <siret...@gmail.com> a écrit :
>
>
> On Thu, Sep 16, 2021 at 4:18 AM Bastien Roucariès 
> <roucaries.bast...@gmail.com> wrote:
>>
>> Package: golang-github-containers-common
>> Version: 0.33.4+ds1-1
>> Severity: critical
>> Tags: upstream
>> Forwarded: 
>> https://github.com/containers/common/commit/42d1db16bfc0dbaee5781d230dc2bcbaa0849c6e
>> Control: fixed -1 0.42.1+ds1-1
>>
>> Dear Maintainer,
>>
>> golang-github-containers-common in stable does not include recent syscall 
>> used
>> by stable kernel/glibc breaking in my case simple container that do 
>> unattended-
>> upgrade on arm
>> particularly syscall=436 that is timer_settime64
>>
>> I believe this should be fixed in a point release.
>
>
> I agree. I realized that these syscall changes also affect amd64. I was able 
> to reproduce the issue
> by running a distribution that ships with glibc 2.34, such as ubuntu impish. 
> The testcase would be:
>
> $ podman run --rm -it ubuntu:impish sh -c 'apt update -qq && apt -y 
> full-upgrade && apt install -y libc6 jq'
>
> The symptom is described in more detail at 
> https://bugs.launchpad.net/ubuntu/+source/libpod/+bug/1943049
>
> The problem here is that the issue is not simply dealt with updating the 
> secomp.json file, but also some code changes are required
> that allow setting the default return value for some syscalls. This means 
> that in order to fix this issue in stable, 3 uploads are needed:
>
> - golang-github-opencontainers-specs
> - golang-github-containers-common
> - libpod
>
> I'm cloning this bug appropriately so that these uploads can be tracked 
> separately.
> For now,I've backported and verified the changes. For your convenience, I've 
> uploaded the packages I got so far to
> https://people.debian.org/~siretart/bug.994451/
>
>>
>> BTW I strongly believe that  seccomp.json is a config file and should be
>> shipped in /etc and 988443  should also be shipped in stable.
>
>
> I could get convinced if the issue was fixable by just upading the 
> seccomp.json policy file.
> Sadly, that's not the case.
It seems that recent version of this package allow to change at exec
time the seccomp.json file.
But for this version, you take the point it need rebuilt.

Note that I have fixed this problem by manually using the unstable
version on my stable.

Bastien


> Stable Release team, I think this bug should be cloned with those 
> instructions:
>
>
> --
> regards,
>     Reinhard

Reply via email to