Reminder Feb 2nd we will have a Podman community meeting.
by Daniel Walsh
Tom Sweeney will be sending out an agenda.
We would love people to play with the podman 3.0 rc1 and rc2 when it
ships to help us improve its stability. Available on Fedora 33/34 now,
and hopefully other distros.
4 years
podman run -It -v /tst:/tst --net=host Xxxx /sbin/Init
by Philip Rhoades
People,
If I build a F33 podman container in a virt-manager built F33 VM, I get
a working podman container but if I try:
ls -al /tst
from there I get:
ls: cannot open directory '/tst/': Permission denied
It appears it is because of selinux in the host VM - if I disable that
and build a new container, I can list /tst as expected . .
Is there a fix or workaround for this situation? Am I finally going to
have to learn about selinux?
Thanks,
Phil.
--
Philip Rhoades
PO Box 896
Cowra NSW 2794
Australia
E-mail: phil(a)pricom.com.au
4 years
Would a new option --disable-subuid make sense?
by Erik Sjölund
The upcoming Podman 3.0 looks exciting, especially in regards to
"rootless single mapping".
Regarding the question:
> If you know of "features", that you want to get in, then make them known
> in github.
Would it make sense to add these two new command-line options to "podman run"
--disable-subuid
--disable-subgid
so that it would easy to disable the use of
/usr/bin/newuidmap
/usr/bin/newgidmap
That would be handy when a user wants to run podman and be sure that
no subuids and subgids are used.
If you wonder about the terminology:
"rootless single mapping", I found it here:
[erik@laptop podman]$ grep "using rootless " ./pkg/rootless/rootless_linux.go
logrus.Warnf("using rootless single mapping into the namespace. This
might break some images. Check /etc/subuid and /etc/subgid for adding
sub*ids")
[erik@laptop podman]$
I could add a feature request to Github, if you think these options make sense.
4 years
We will be preparing the first release candidate for Podman 3.0 this week.
by Daniel Walsh
Once it is available, we would like to get as many people as possible
playing with the release candidates, to improve the 3.0 quality.
If you know of "features", that you want to get in, then make them known
in github.
If you are working on features/bugfixes you want to get in, please try
to complete them early in the week.
Podman 3.0 should be a great release...
4 years
Getting Docker Discourse running with Podman
by Philip Rhoades
People,
I can run the discourse image with docker, export the container and
import it as an image into podman.
The script that manages docker discourse containers is:
/var/discourse/launcher
and is attached. It would be good if it were possible to just replace
all the occurrences of "docker" with "podman", fix version numbers etc
and be able to use the script - but can any gurus see dockerisms in the
script that will cause podman gotchas for this idea?
Thanks,
Phil.
--
Philip Rhoades
PO Box 896
Cowra NSW 2794
Australia
E-mail: phil(a)pricom.com.au
4 years
LInux Capabilities for a container
by Jorge Fábregas
Hi,
Is there an easy way to figure out which capabilities are needed for a
container other than playing out with the cap-drop & cap-add options?
Thanks.
--
Jorge
4 years, 1 month
Change in rootful userns container capabilities?
by Joost Molenaar
Hello all,
When I upgraded podman from 2.1.1 to 2.2.1, my wireguard container stopped
working because wg-quick returned a 'permission denied' error. After some
bug hunting, I found out that starting a (rootful) container like this...
podman run --rm --uidmap 0:60000:1000 --gidmap 0:60000:1000 \
docker.io/library/alpine:3.12 \
grep ^Cap /proc/self/status
...on podman 2.1.1 returns a capability mask of a80425fb for all of CapInh,
CapPrm, CapEff, CapBnd and CapAmb, and on podman 2.2.1 returns 800405fb for all
of the capability masks except for CapAmb, which is all zeroes.
So on podman 2.1.1 my rootful usernamespaced container ran with these capabilities:
0x00000000a80425fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
And on podman 2.2.1 with these:
0x00000000800405fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_sys_chroot,cap_setfcap
So, containers no longer run with CAP_NET_RAW, CAP_MKNOD and CAP_AUDIT_WRITE,
which for for my wireguard container means I now have to `--cap-add`
CAP_NET_RAW in addition to CAP_NET_ADMIN, because `wg-quick` runs `iptables`,
which opens some raw sockets to communicate with the kernel.
I wonder what is the background of this change, is it intentional? And I also
noticed CapAmb is now all zeroes, which seems to have to do with commit bce8f8
[1], but reading the code I don't understand why CapAmb is now empty when it
seems to be the intention to populate it.
Regards,
Joost Molenaar
[1] https://github.com/containers/podman/commit/bce8f851c1e891aa6159e61c56ccd...
4 years, 1 month
