9:58 a.m.
On 10/5/21 09:35, Tobias Wendorff wrote:
Dear Adrian,
Am 05.10.2021 um 09:44 schrieb Adrian Reber:
> I am really confused about the translation layer you are mentioning I
> have not heard of it before.
Me neither. That's why I asked.
> I just had a short chat with the core LXC maintainer and he also says
> this email is mainly confusing. It seems like your source of information
> is not reliable of confusing certain concepts. Can you maybe be a bit
> more specific what you are looking for?
Those were not my words. I've just refactored some sentences in a long
discussion about the benefits of a rootless and daemonless Podman vs.
LXC (I got the permission to repost them).
I'll talk to him again. Maybe he also was confused.
Thanks for your reply,
Tobias
_______________________________________________
Podman mailing list -- podman(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io
Perhaps lxcd is using some kind of seccomp filtering kernel. Podman
theoretically supports gVistord as a OCI Runtime, which intercepts all
Syscalls of the container. You could also use kata oci runtime to do the
syscalls within a qumu kvm process. libkrun provides similar functionality.
Bottom line by default rootless Podman communicates with the host kernel
just like normal user processes, with tools like SELinux, Seccomp
filtering and user namespace to further isolate the processes.
A kernel vulnerability with standard traditional OCI Runtimes, could
lead to a privilege escallation with these containers. If you run with
another syscall intercepter or with kvm, you get better isolation.
Podman can run in either mode.