Bug#1012030: (no subject)

[Reinhard Tartler]

Control: reassign -1 runc 1.0.0~rc93+ds1

Shengjing, you are right (as always),

I can confirm that backporting this patch does fix this issue:
https://salsa.debian.org/go-team/packages/runc/-/commit/1d73689985b29ec5b8477dbc6df8004aa09771d1

I'll upload to stable and request it to be unblocked shortly.

On Tue, May 31, 2022 at 12:10 AM Shengjing Zhu  wrote:

> On Tue, May 31, 2022 at 3:33 AM Reinhard Tartler 
> wrote:
> >
> >
> > I wonder whether this may be related to upstream report at
> https://github.com/containers/common/issues/631
> >
> > It seems that in debian/bullseye, podman is only able to work in crun,
> since the version of runc we have in stable seems to have issues with
> seccomp. Can you please try the following for me with both crun and runc
> installed:
> >
> > root@pve:~# podman run --runtime runc
> --security-opt=seccomp=unconfined  --rm -it debian date
> > Mon May 30 19:18:05 UTC 2022
> >
> > That does appear to work at least on my system.
> >
> > This might indicate that this is actually a change that needs to go into
> golang-github-containers-common then...
> >
>
> If I read the issue correctly, it's because in the last stable update,
> the defaultErrnoRet feature is backported. However runc doesn't
> support it until v1.0.0-rc95(stable has rc93). I don't think runc will
> get feature backports in stable. So probably only crun can be used by
> podman now in stable.
>
> --
> Shengjing Zhu
>


-- 
regards,
Reinhard

Bug#1012030: (no subject)

[Shengjing Zhu]

On Tue, May 31, 2022 at 3:33 AM Reinhard Tartler  wrote:
>
>
> I wonder whether this may be related to upstream report at 
> https://github.com/containers/common/issues/631
>
> It seems that in debian/bullseye, podman is only able to work in crun, since 
> the version of runc we have in stable seems to have issues with seccomp. Can 
> you please try the following for me with both crun and runc installed:
>
> root@pve:~# podman run --runtime runc  --security-opt=seccomp=unconfined  
> --rm -it debian date
> Mon May 30 19:18:05 UTC 2022
>
> That does appear to work at least on my system.
>
> This might indicate that this is actually a change that needs to go into 
> golang-github-containers-common then...
>

If I read the issue correctly, it's because in the last stable update,
the defaultErrnoRet feature is backported. However runc doesn't
support it until v1.0.0-rc95(stable has rc93). I don't think runc will
get feature backports in stable. So probably only crun can be used by
podman now in stable.

-- 
Shengjing Zhu

Bug#1012030: (no subject)

[Vicente Olivert Riera]

Dear Reinhard Tartler,

I have tried what you suggested, and indeed, it does work. See:

$ # CHECK BOTH CRUN AND RUNC ARE INSTALLED
$ dpkg -s runc | grep -E '^Status'
Status: install ok installed
$dpkg -s crun | grep -E '^Status'
Status: install ok installed
$ # RUN COMMAND WITHOUT THE SUGGESTED WORKAROUND
$ podman run --runtime runc --rm -it debian date
Error: container_linux.go:367: starting container process caused: error 
adding seccomp filter rule for syscall bdflush: permission denied: OCI 
permission denied

$ # RUN COMMAND WITH THE SUGGESTED WORKAROUND
$ podman run --runtime runc --security-opt=seccomp=unconfined --rm -it 
debian date

Mon May 30 23:33:32 UTC 2022

Thanks,
Vincent

On 31/05/2022 04:28, Reinhard Tartler wrote:


I wonder whether this may be related to upstream report at 
https://github.com/containers/common/issues/631 



It seems that in debian/bullseye, podman is only able to work in crun, 
since the version of runc we have in stable seems to have issues with 
seccomp. Can you please try the following for me with both crun and 
runc installed:


root@pve:~# podman run --runtime runc  --security-opt=seccomp=unconfined 
  --rm -it debian date

Mon May 30 19:18:05 UTC 2022

That does appear to work at least on my system.

This might indicate that this is actually a change that needs to go into 
golang-github-containers-common then...


On Mon, May 30, 2022 at 9:15 AM Vicente Olivert Riera 
> wrote:


I've found the problem appears to be between podman and runc.

I have runc installed in my system because I also use docker.io
, and
that package depends on it.
runc is also a dependency of podman, so podman uses it. However, podman
can also use crun. But, since runc was already installed, and podman
can
depend on either of them, crun was not installed as a dependecy.

Now, if I manually install crun, podman works again and the error is
gone. I think if podman finds that crun is installed, it will use it.
Otherwise it will use runc as a fallback.

Since both runc and crun packages can coexist in the system, I think a
quick fix could be removing the runc dependency on podman, so it will
always pull in crun as a dependency. At least until the root cause of
this problem is found and fixed.



--
regards,
     Reinhard


OpenPGP_0x5DE0950419F6E531.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012030: (no subject)

[Reinhard Tartler]

I wonder whether this may be related to upstream report at
https://github.com/containers/common/issues/631

It seems that in debian/bullseye, podman is only able to work in crun,
since the version of runc we have in stable seems to have issues with
seccomp. Can you please try the following for me with both crun and
runc installed:

root@pve:~# podman run --runtime runc  --security-opt=seccomp=unconfined
 --rm -it debian date
Mon May 30 19:18:05 UTC 2022

That does appear to work at least on my system.

This might indicate that this is actually a change that needs to go into
golang-github-containers-common then...

On Mon, May 30, 2022 at 9:15 AM Vicente Olivert Riera <
vincent.olivert.ri...@gmail.com> wrote:

> I've found the problem appears to be between podman and runc.
>
> I have runc installed in my system because I also use docker.io, and
> that package depends on it.
> runc is also a dependency of podman, so podman uses it. However, podman
> can also use crun. But, since runc was already installed, and podman can
> depend on either of them, crun was not installed as a dependecy.
>
> Now, if I manually install crun, podman works again and the error is
> gone. I think if podman finds that crun is installed, it will use it.
> Otherwise it will use runc as a fallback.
>
> Since both runc and crun packages can coexist in the system, I think a
> quick fix could be removing the runc dependency on podman, so it will
> always pull in crun as a dependency. At least until the root cause of
> this problem is found and fixed.
>


-- 
regards,
Reinhard

Bug#1012030: (no subject)

[Vicente Olivert Riera]

I've found the problem appears to be between podman and runc.

I have runc installed in my system because I also use docker.io, and 
that package depends on it.
runc is also a dependency of podman, so podman uses it. However, podman 
can also use crun. But, since runc was already installed, and podman can 
depend on either of them, crun was not installed as a dependecy.


Now, if I manually install crun, podman works again and the error is 
gone. I think if podman finds that crun is installed, it will use it. 
Otherwise it will use runc as a fallback.


Since both runc and crun packages can coexist in the system, I think a 
quick fix could be removing the runc dependency on podman, so it will 
always pull in crun as a dependency. At least until the root cause of 
this problem is found and fixed.


OpenPGP_0x5DE0950419F6E531.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature