On 18/01/2023 03:52, Richard Hector wrote:
On 17/01/23 23:52, Max Nikulin wrote:
lxc.idmap = u 0 100000 1000
lxc.idmap = u 1000 1000 1
lxc.mount.entry = /home/richard/sitename/doc_root
srv/sitename/doc_root none bind,optional,create=dir
My goal is not to map container users to host users, but to allow a
container user (human user) to access a directory as another container
user (non-human owner of files). This should also be doable for multiple
human users for the same site.
Do you mean mapping several users (human and service ones) from a single
container to the same host UID? The approach I suggested works for 1:1
mapping. Another technique is group permissions and ACLs, but I would
not call it straightforward. A user may create a file that belongs to
wrong group or inaccessible by another user.
I would look into lxcfs hook for inspiration
Interesting; will do. Not sure exactly where to start, but will get there.
/usr/share/lxcfs/lxc.mount.hook (lxcfs package)
lxc-device -n ${LXC_NAME} add /dev/fuse
Is there any reason why it can not be done using lxc.mount.entry in
the container config?
Is that usable for adding a device file? The only way I found to do that
is using lxc-device from outside the container. mknod inside doesn't work.
I use it to pass /dev/dri and /dev/video0 to a container. The only issue
is that the webcam is a USB device, so permissions become wrong after
suspend to RAM and the following resume.
lxc-attach -n ${LXC_NAME} /usr/local/bin/bindfs_mount
I would consider adding a systemd unit inside container. Unsure if
could be done using an udev rule.
That might be better, but it does need to rely on the device existing
first.
I see no difference since in your approach device presence is ensured by
a hook. With a lxc.mount.entry it should be even more reliable.
So even for running stuff manually, run it from systemd? Interesting,
will investigate further. I wasn't aware of systemd-run.
I use unprivileged containers to experiment with applications packaged
for other linux distributions or just in relatively isolated
environment. My experience that even after searching for particular
errors it is not obvious what should be done to fix it.
Delegate=yes is mandatory for lxc-start. To attach:
systemd-run --user --scope --property=Delegate=yes -- \
lxc-attach --clear-env --keep-var TERM ...
At first I tried --pty instead of --scope for interactive sessions, but
I noticed some issues as well.
-
https://discuss.linuxcontainers.org/t/pam-cgfs-how-to-setup-with-cgroup-v2/10741/
"Pam_cgfs How to setup with cgroup v2?"
- https://github.com/lxc/lxc/issues/3221#issuecomment-648829685
"Unable to start an unprivileged container on fresh install of Fedora
31 · Issue #3221 · lxc/lxc"
