owned this note
owned this note
Published
Linked with GitHub
# Podman Community Cabal Agenda
One hour meeting on the third Tuesday of every month at 11:00 a.m. US/Eastern (UTC-5) to deep dive into topics on the agenda. **Please add your name at the end of the topic so we know who the topic owner is.**
Meeting ID: https://meet.google.com/xrq-uemd-bzy
Try out [WorldTimeBuddy](https://www.worldtimebuddy.com/?qm=1&lid=6167865,3435910,2643743&h=6167865&date=2024-04-16&sln=11-12&hf=1)
### Attendees
### April 16, 2024 Topics
### Meeting Notes
Video [Recording]()
Meeting start 11: a.m. Tuesday, April 16, 2024
1. Data production for appliances backup application - Vikas Goel
#### Data production for appliances backup application - Vikas Goel - (: in the video) - 2
Data production appliance, a black box for Veritas customers. It's a platform with specicialized for the their customers. There are multiple applications that can be used, and they're securely signed. Appliance custoemrs can upload their own particular software and version.
Data production application runs in non-root containers in a hardened environment. Some of them applications expose the luns. Customers can also decide which ports they want to access.
Luns are exported as devices so the application can access them. The application can't create a device inside of the container. VMware can change the devices in the environment. For Veritas, making these new devices available inside of the container has been problematic. THis has caused problematic.
Can we make new devices exposed to a running container?
Matt ran working on podman update, and he ran across code that had stopped that from happening. Podman could potentially mount up the devices if the devices was specified in a known folder. Matt doesn't know if we can do without restarting a containers. HE thinks it might be best to manage this through a directory that's opened at the container start time.
In the past Veritas had been moving the devices to a separate folder. THey ran into issues when systemd restarted any service, it made the devices invalid.
Dan (get chat) - 10
Dan thought about a bind mount, but didn't know that it would work rootless.
Vikas thinks they tried that, but ran into problems, he needs to check.
Toolbox is playing around in this area where they escape the container and add devices. You need to be careful to do this securely. You have to make sure the SeLinux labels are all lined up. Dan offered to act as a contact.
They had been using a directory in RHEL 7, but not working now.
The other issue is similar, working with volumes. They'd like to be able to increase the volume size. The problem is when you add a new volume, you need to restart.
You could join the mount namespace, then you should be able to mount. However, you'd only be able to see the volumes within the container.
Vikas asked if there could be a cleaner interfaces. The supported way would be to do autofs or something similar where you could add volumes to that. For instance, create a container with a volume under /mount, then if you create a /mount/foo or /mount/bar, you could see the device.
Vikas had looked at this, but believes there is a security issue with that approach that he discovered. So Veritas didn't go that way.
Vikas wonders if they could could do a volume mount into the container. WHen Podman starts a container, we create a mount namespace and then we start mounting there, but after that can't mount ontop of it at the moment. So we can't see new mounts on the host unless the host mounts something into a namespace the container already has mounted.
Paul thinks the new mount api's might help in this area. But that doesn't help with the current software. Paul says this is part of OSCI mounting and not really something a container can change or manipulate.
Dan thinks if we can do something, it should be done as a tool outside of Podman itself. In RHEL 9+, you can open a file descriptor to a mount, then you can join that later. This is a new feature.
Security issues here are leaking files from the host into the container, that's the main challenge in this space.
You could possibly create a process to inject a new mount point, but the admin doing this needs to be sure it's done correctly.
RHEL 9 has the kernel changes to make this happen more easily, Vikas will go investigate further.
Vikas also had a question on iscsi support on the kernel. POdman depends mostly on bindmounts, and Dan would prefer to keep iscsi outside of the containers.
The Linux Kernel only allow a small subset of filessytems, and that's all that's allowed in rootless mode.
Vikas noted that someone from Suse had looked into adding an iscsi namespace and was wondering what the challenges are? Dan's not sure, but noted that dealing with API's not being aware of namespaces outside of the container.
Vikas thinks a number of containers can each have iscsi namespace, but the containers keep their own setup, and can't see outside.
Vikas had seen a patch, but it didn't go through. Dan suggested contacting the developer. Dan also suggested touching base with the Red Hat Kernel team.
#### Dan Walsh - emulation mode
Running the commands, Podman, Buildah, Skopeo in emulation mode is not working at the moment due to a reexec issue with argv0. Emulation mode runs argv1 inside of argv0. I.e., can't touch `/` with Skopeo in emulation. Dan doesn't know what the fix is. This is a QEMU issue that has had a bug on it since 2020.
#### Open discussion - (: in the video) -
1. None
### Next Cabal Meeting: Tuesday, May 21, 2024, 11:00 a.m. EDT (UTC-5)
#### Possible Topics
1.
### Next Community Meeting: Tuesday, June 4, 2024, 11:00 a.m. EDT (UTC-5)
#### Possible Topics:
bootc demo
Meeting finished 11: a.m.
### Raw Meeting Chat:
```
You
11:12 AM
Vikas, fyi, that's Dan Walsh talking
You
11:17 AM
Vikas: dwalsh@redhat.com
Paul Holzinger
11:25 AM
https://brauner.io/2023/02/28/mounting-into-mount-namespaces.html
```
### Raw Google Meet Transcript
```
```