Thanks for your kind reply and for the link @ricardodacosta
May be it would be nice to include a couple of examples in the official documentation attending that this is a required objective for EX200.
The reason I don't have access to that course would be another interesting issue to be discussed in the right thread. Anyway, beyond thanking your time, I'd like to confirm the procedure for non-root containers in case someone could need it.
I found two working approaches. Both of them presume having the requested volume mounted in a folder owned by the non-root user owner of the container, with o+w permissions:
Mount:
This approach require three steps, two if you don't want to create a policy but just relabel the context directly in the fs.
$ podman create --d --name nonroot-cont-name -p 8080:80 --mount type=bind,src=/mnt/point,target=/dest/point <RG/NS/N>
# semanage fcontext -a -t svirt_sandbox_file_t "/mnt/point(/.*)?"
# restorecon -Rv /mnt/point
NOTE: At the end of the relabeling process the actual context will be container_file_t.
Volume
This approach only required one step as the relabeling in this case is on account of podman due to the 3rd field (z if the resource is intended to be shared by two or more containers, Z just for this one making it private):
$ podman create --d --name nonroot-cont-name -p 8080:80 -v /mnt/point:/dest/point:z <RG/NS/N>
NOTE: As suggested by the documentation, the use of a volume name and not the path is recommended as in some cases it can be marked as an orphan and wiped if pruned.
Final Thoughts:
1. I wonder if both, one or none of the solutions would be accepted in EX200 as described here.
2. I don't quite feel the diference between using volumes instead of bind mounting from an operational PoV.
Thanks
