[Virtio-fs] [virtiofsd-rs] user namespace progress report

[Virtio-fs] [virtiofsd-rs] user namespace progress report

[German Maglione]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

Hi,

I have been performing several tests to see if it is possible to run the
virtiofs-rs daemon inside a user namespace. It works with both 'none' and
'chroot' sandbox modes. But, file handles don't work.

I tested it using 'unshare', 'podman unshare' and 'lxc-usernsexec'
(the lxc one give us more flexibility when mapping [g|u]ids)

I also ran pjdfstests and only tests that run 'mknod' fails(*), expected
when
executed as a non-privileged user.
(*) I've not finished checking all failed test.

Next step is to get it to run in libvirt session mode.

Cheers,

-- 
German

[-- Attachment #2: Type: text/html, Size: 821 bytes --]

Re: [Virtio-fs] [virtiofsd-rs] user namespace progress report

[German Maglione]

[-- Attachment #1: Type: text/plain, Size: 2650 bytes --]

I forget to mention that I tested it with selinux disabled for both the
host and the guest.
But, I plan to test it with selinux enabled.

Just a quick summary of how to run it:

With /etc/subuid and /etc/subgid
german:100000:65536

$ podman unshare -- <virtiofsd-rs_path>/target/debug/virtiofsd-rs
--socket-path /tmp/vfsdsock --shared-dir shared/  --sandbox none &

(this is just to check the g|uid map)
$ nsenter -U -t $(pidof virtiofsd-rs)
# cat /proc/self/uid_map
         0       1000          1
         1     100000      65536

'podman unshare' always maps the user to "root" and any range which
match the user in /etc/subuid and /etc/subgid.
You can get the same result with unshare, newuidmap and newgidmap

0$ unshare -U
0$ $$
bash: 17816: command not found...

(in a different terminal)
1$ newuidmap 17816 0 1000 1
1$ newgidmap 17816 0 1000 1
1$ newuidmap 17816 1 100000 65536
1$ newgidmap 17816 1 100000 65536

(now in the first terminal)
0$ <virtiofsd-rs_path>/target/debug/virtiofsd-rs --socket-path
/tmp/vfsdsock --shared-dir shared/  --sandbox none &

We _must_ run virtiofsd-rs after making the uid/gid mapping.

In both cases, when the guest-root creates a file in the shared directory,
the real uid will be 1000 (for the uid 1 -> 100000, and so on)

With lxc-usernsexec it's a bit different, we could leave the user (german
in this case)
outside the mapping:

$ lxc-usernsexec -m b:0:100000:65536 --
<virtiofsd-rs_path>/target/debug/virtiofsd-rs --socket-path /tmp/vfsdsock
--shared-dir shared/  --sandbox none &

$ nsenter -U -t $(pidof virtiofsd-rs)
# cat /proc/self/uid_map
         0     100000      65536

Now, the guest-root will be the uid 100000.

Or if we want the same behavior that 'podman unshare'
$ lxc-usernsexec -m b:0:1000:1 -m b:1:100000:65536 --
<virtiofsd-rs_path>/target/debug/virtiofsd-rs --socket-path /tmp/vfsdsock
--shared-dir shared/  --sandbox none &

We could also select '--sandbox chroot'

Cheers,



On Wed, Dec 15, 2021 at 11:54 AM German Maglione <gmaglione@redhat.com>
wrote:

> Hi,
>
> I have been performing several tests to see if it is possible to run the
> virtiofs-rs daemon inside a user namespace. It works with both 'none' and
> 'chroot' sandbox modes. But, file handles don't work.
>
> I tested it using 'unshare', 'podman unshare' and 'lxc-usernsexec'
> (the lxc one give us more flexibility when mapping [g|u]ids)
>
> I also ran pjdfstests and only tests that run 'mknod' fails(*), expected
> when
> executed as a non-privileged user.
> (*) I've not finished checking all failed test.
>
> Next step is to get it to run in libvirt session mode.
>
> Cheers,
>
> --
> German
>


-- 
German

[-- Attachment #2: Type: text/html, Size: 3967 bytes --]