On 17/01/23 23:52, Max Nikulin wrote:
On 17/01/2023 04:06, Richard Hector wrote:
I'm using bindfs in my web LXC containers to allow particular users to
write to their site docroot as the correct user.
I am not familiar with bindfs, so I may miss something important for
your use case.
First of all I am unsure why you prefer bindfs instead of mapping some
container users to host users using namespaces. With the following
configuration 1000 inside a container and on the host is the same UID:
lxc.idmap = u 0 100000 1000
lxc.idmap = u 1000 1000 1
lxc.idmap = u 1001 101001 64535
lxc.idmap = g 0 100000 1000
lxc.idmap = g 1000 1000 1
lxc.idmap = g 1001 101001 64535
lxc.mount.entry = /home/richard/sitename/doc_root /srv/sitename/doc_root
none bind,optional,create=dir
Disclaimer - I haven't actually tried any of your suggestions yet.
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.
In /usr/local/bin/fuse.hook:
I would look into lxcfs hook for inspiration
Interesting; will do. Not sure exactly where to start, but will get there.
In /usr/local/bin/fuse.hook.s2:
========================================================================
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.
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.
If I don't use the at job, but run those commands manually after boot,
it works fine with no error messages.
Unsure if it is relevant, but it is better to run lxc-start and
lxc-attach as a systemd unit with Delegate=yes configuration, either a
temporary one (systemd-run) or configured as a service. It ensures
proper cgroup and scope. Otherwise some cryptic errors may happen.
So even for running stuff manually, run it from systemd? Interesting,
will investigate further. I wasn't aware of systemd-run.
Thanks,
Richard
