<div dir="ltr">Thanks German! We have been able to patch the virtiofsd code to map a range of IDs. We are using systemd service to run virtiofsd as a non-privilege user and its <a href="https://www.freedesktop.org/software/systemd/man/systemd.exec.html#AmbientCapabilities=">AmbientCapabilities</a> set to SETUID and SETGID. We've defined two new parameters for --uid-map and --gid-map. The patch sets temporary caps for the running process (SETUID/SETGID), writes the mapping according to the input parameters and at the end it drops those temporary capabilities. Do you see any value in upstreaming this patch? Thanks!</div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 26, 2022 at 8:47 AM German Maglione <<a href="mailto:gmaglione@redhat.com">gmaglione@redhat.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Aug 26, 2022 at 5:27 PM German Maglione <<a href="mailto:gmaglione@redhat.com" target="_blank">gmaglione@redhat.com</a>> wrote: > > On Thu, Aug 18, 2022 at 1:16 AM Elaheh Dehghani <<a href="mailto:dehghani.e@gmail.com" target="_blank">dehghani.e@gmail.com</a>> wrote: > > > > We are using an unprivileged user to run virtiofsd in its own user namespace. We have a guest VM running on top of QEMU with KVM. We are sharing files from the host to the guest and we need to make sure only certain users/groups in the guest can read/write those files. Currently there is only one uid/gid that’s mapped correctly (the virtiofsd user on the host is mapped to guest) and everything else is mapped to nobody. > > > > It seems the reason is that unprivileged virtiofsd only maps current uid/gid when it's running inside its own user namespace. > > > > Due to some resource limitations that we have in our system, we can't use a container-engine such as lxc-usernsexec to map a range of uids/gids. So, I'm trying to figure out if there is a way to patch the ‘setup_id_mappings’ in virtiofsd code to support our specific scenario. > > > > > > The additional mapping that we need is for uid/gid=1000. What I've done: > > > > - Defined 1000:100000:65536 in both /etc/subuid and /etc/subgid > > > > - Changed this line src/<a href="http://sandbox.rs" rel="noreferrer" target="_blank">sandbox.rs</a> · main · virtio-fs / virtiofsd · GitLab to something like: > > > > - let uid_mapping = format!("{} {} 1\n1000 1000 1\n", uid, uid); > > > > > > After running virtiofsd, I’m getting this error: > > > > Error entering sandbox: WriteUidMap(Os { code: 1, kind: PermissionDenied, message: “Operation not permitted” }) > > > > > > What am I missing here? > > As non-privilege user, you are only allowed to map the user UID -> > same NS-UID (as virtiofsd does) or user UID -> NS-UID 0, > by writing directly to '/proc/PID/{uid_map, gid_map}. > > Mapping a range of UIDS/GUIDS is a privileged operation, you need to > set the content of both '/etc/subuid' and '/etc/subgid ' > and run newuidmap/newgidmap. > > You could "manually" create the user namespace with "unshare -U", map > the uids/guid using newuidmap/newgidmap, and run virtiofsd > --sandbox=chroot > For instance (as user 1000): > > shell_0_$ unshare -U > shell_0_$ echo $$ > 1234 > > (in a different terminal) > shell_1_$ newuidmap 1234 0 100000 65536 > shell_1_$ newgidmap 1234 0 100000 65536 > > (now in the previous terminal) > shell_0_$ virtiofsd --sandbox=chroot ... > > Although lxc-usernsexec is a small tool that only creates user > namespaces and calls newuidmap/newgidmap to do the uid/gid mapping > I forgot to mention, as an alternative you can patch the virtiofsd code removing the 'setup_id_mapping()' call. So you can run virtiofsd --sandbox=namesapce ... and then just call newuidmap/newgidmap with the virtiofsd PID Cheers, -- German </blockquote></div>