[Virtio-fs] Map more than one uid/gid when running virtiofsd with unprivileged user

[Elaheh Dehghani]

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
AmbientCapabilities
<https://www.freedesktop.org/software/systemd/man/systemd.exec.html#AmbientCapabilities=>
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!

On Fri, Aug 26, 2022 at 8:47 AM German Maglione <gmaglione at redhat.com>
wrote:

> On Fri, Aug 26, 2022 at 5:27 PM German Maglione <gmaglione at redhat.com>
> wrote:
> >
> > On Thu, Aug 18, 2022 at 1:16 AM Elaheh Dehghani <dehghani.e at gmail.com>
> 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/sandbox.rs · 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/virtio-fs/attachments/20220826/61152c2c/attachment-0001.htm>