12:21 a.m.
OK, so, I have a thing I wrote (https://github.com/lojban/lbcs) that
does its own simple isolated rootless container management. It
starts a pod and then starts a configurable list of containers
within the pod.
https://github.com/containers/podman/issues/12669#issuecomment-998845927
completely broke one of my setups. Which is fine, but I want to
know what I should be doing instead.
I'm sure it's possible that where I'm going wrong is not where I'm
expecting, so I'm going to try to lay out the whole situation.
Here's the situation. I have a pod in which I run exim,
spamassassin, and clamav. I'm running it rootless, as a user made
for this purpose. Let's say the user's UID is 1000, cuz, you know,
tradition.
I have several things mounted into the containers as a method of
persistence, such as exim's spool directory, clamav's definitions
dir, etc.
Because I'm running rootless, all those files are owned by UID 1000,
as you'd expect. I also run with --userns=keep-id, because, well,
that seems cleanest and most secure? Running thigs as root in the
container seems bad? I'm not sure I actually have a strong
principled reason to be doing that, so let me know if it's a bad
plan.
However, daemons tend to want to run as their own user, so my
standard pattern is:
RUN for user in mail clamupdate clamscan ; \
do \
find / -xdev -user $user -print0 | xargs -r -0 chown <%= userid %> ; \
usermod -o -u <%= userid %> $user ; \
done
, where "<%= userid %>" is replaced with "1000" by the
templating
thingy. So: change the UID of the system user that the daemon runs
at to 1000, and change all files owned by that user to 1000.
This all works fine, I do it in many places, it's fine.
Here's the problem:
exim will *only* run as UID 93.
It is, I shit you not, baked in at compile time ;_;. (See
https://src.fedoraproject.org/rpms/exim/blob/rawhide/f/exim-4.96-config.p...
and
https://github.com/Exim/exim/blob/cf5f5988102b229ef87bc85ba3f0a9ec265f28a...
). I'm running from the Fedora RPMs. I do not want to roll my own.
I want to pass the network connection between clamav and exim across
localhost, because why have the network connection transit out of
containers?
So what I *used* to have was:
$ podman pod create --share=net --network
slirp4netns:mtu=30000,port_handler=slirp4netns --userns=keep-id -n drata -p 20280:20280 -p
20225:20225 -p 20265:20265 --network slirp4netns:outbound_addr=192.168.123.132
$ podman run --pod=drata --log-driver=none --name exim -t --uidmap 0:1:92 --uidmap
93:0:1 --uidmap 94:95:8192 -v
/home/spdrata/misc-containers/shared_data/var_spool/:/var/spool -v
/home/spdrata/misc-containers/shared_data/srv_lojban:/srv/lojban -i spdrata/drata-exim:1
, and that worked fine. The uidmap maps the user running the
rootless container (UID 1000) on the host to UID
93 in the container.
(Side comment: the documentation for uidmap is *terrible*; coming up
with that uidmap set to do what I want took me *hours* of
experimentation.)
This now simply refuses to work.
So what I'm doing instead is I moved the uidmap onto the pod,
instead of remapping all the system/daemon users to UID 1000, I
remap them to UID 93.
This seems ... icky?, but maybe it's the right way to do it?
Honestly not sure. Looking for advice.
Thanks if you read this far! :D
5:04 p.m.
On 7/19/22 00:21, Robin Lee Powell wrote:
remap them to UID 93.
Oof, this is really tough. I'm really surprised the UID is hard-coded
like that. Are you seriously locked into using exim?
(I'm guessing yes).
On 7/19/22 00:21, Robin Lee Powell wrote:
Because I'm running rootless, all those files are owned by UID
1000,
as you'd expect. I also run with --userns=keep-id, because, well,
that seems cleanest and most secure?
I'm thinking this might be your way out. If the containers were running
as root on the host, there would be a security benefit to non-root
container users. However, since you're running rootless, you're really
not gaining anything at all (besides maybe frustration).
So, since you're hard-coded into uid 93 for exim, can you rearrange all
your non-exim containers to run as root (still rootless on the host) but
retain access the volume data that's needed?
Another idea is to have all your non-exim containers run with
`--userns:container:<Exim Container>` to help coordinate access to your
volume data. That should also reduce the amount of fiddling you need to
do with UIDs/GIDs. Everything can simply be locked into whatever is
setup in the exim container.
HTH
--
Chris Evich (he/him), RHCA III
Senior Quality Assurance Engineer
My personal robot overlord told me to include this signature line.
12:41 a.m.
On Tue, Jul 26, 2022 at 05:04:38PM -0400, Chris Evich wrote:
On 7/19/22 00:21, Robin Lee Powell wrote:
> remap them to UID 93.
Oof, this is really tough. I'm really surprised the UID is hard-coded like
that. Are you seriously locked into using exim?
(I'm guessing yes).
Given that it looks like postfix has one in most of the world, I've
certainly considered it, but that'd be a different project.
On 7/19/22 00:21, Robin Lee Powell wrote:
> Because I'm running rootless, all those files are owned by UID 1000,
> as you'd expect. I also run with --userns=keep-id, because, well,
> that seems cleanest and most secure?
I'm thinking this might be your way out. If the containers were
running as root on the host, there would be a security benefit to
non-root container users. However, since you're running rootless,
you're really not gaining anything at all (besides maybe
frustration).
So, since you're hard-coded into uid 93 for exim, can you
rearrange all your non-exim containers to run as root (still
rootless on the host) but retain access the volume data that's
needed?
So that would be *not* running with --userns=keep-id, so container 0
maps to my local UID?
The problem there is that the other things all drop priv to their
own user, like clamav has a user and so on, which is why my current
config changes the clamav UID to match my local UID to go with
--userns=keep-id
Another idea is to have all your non-exim containers run with
`--userns:container:<Exim Container>` to help coordinate access to
your volume data. That should also reduce the amount of fiddling
you need to do with UIDs/GIDs. Everything can simply be locked
into whatever is setup in the exim container.
I think I followed that.
In both cases, though, I'd still need the --uidmap on the exim
container to map container user 93 to my local UID, yes?
5:05 p.m.
On 7/27/22 00:41, Robin Lee Powell wrote:
I think I followed that.
In both cases, though, I'd still need the --uidmap on the exim
container to map container user 93 to my local UID, yes?
I could be wrong, I'm not an expert in these things and your setup is
complex. I think that perhaps the local UID doesn't matter. What
matters is coordinating the mapping across all the containers, so they
all have the same "view". Otherwise the UID/GIDs of files/directories
in your (presumably shared) volume-mounts won't line up. Though...if
you're not sharing any volumes between the containers, then I s'pose
this doesn't apply.
The point is, as long as you're running rootless, the actual mapping
values on the host shouldn't matter (assuming the containers are happy
with their user namespace). If you need to pass ---uidmap in at runtime
to make the containers happy (depending on how the images are built),
it's okay, but if you can avoid it entirely, that's probably going to
result in easier maintenance and updates.
--
Chris Evich (he/him), RHCA III
Senior Quality Assurance Engineer
My personal robot overlord told me to include this signature line.
1026
days inactive
1039
days old
3 comments
2 participants
participants (2)
-
Chris Evich -
Robin Lee Powell