Bug 2141629

Summary: [virtiofsd] Keep `DAC_OVERRIDE` after changing the uid/gid
Product: Red Hat Enterprise Linux 9 Reporter: German Maglione <gmaglione>
Component: virtiofsdAssignee: German Maglione <gmaglione>
Status: CLOSED ERRATA QA Contact: xiagao
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 9.2CC: coli, gkurz, jinzhao, juzhang, mszeredi, qizhu, slopezpa, vgoyal, virt-maint, xiagao
Target Milestone: rcKeywords: FutureFeature, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: virtiofsd-1.5.0-1.el9 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-05-09 07:46:45 UTC Type: Feature Request
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2123070    
Bug Blocks:    

Description German Maglione 2022-11-10 10:39:12 UTC
Description of problem:

Fuse does not send supplementary group information to the file server. This causes some use cases to fail.

This limitation has resulted in an issue with virtiofs in kata containers. A user is trying to run a database inside kata container and that fails on top of virtiofs.

https://issues.redhat.com/browse/KATA-1776


Although the actual solution requires a modification of the FUSE
protocol (Bug 2134128), in the meantime and also to support kernels without the new FUSE protocol, we can partially work around this, setting the DAC_OVERRIDE in the capabilities effective set after changing the credentials.

This workaround, might be limited to local filesystems, it will not work on top of NFS (and probably also CEPH).


How reproducible:
100%

Steps to Reproduce:
1. start virtiofsd
2. start the guest.
3. (in guest) mount the virtiofs
root#  mount -t virtiofs myfs mmm/

4. (in guest) add a user and it to the wheel group (as supplementary group)
root# useradd u1
root# passwd u1
root# usermod -G wheel u1

5. (in guest) as root, create a test directory
root# mkdir -m 0770 testdir
root# chgrp wheel testdir

6. (in guest) switch to u1 user and try to create a file inside the test directory
root# su u1
u1$ touch testdir/file


Actual results:
fails with "Permission denied"

Expected results:
# ls -l testdir/file 
-rw-r--r-- 1 user user 0 nov 10 11:12 testdir/file

Comment 1 xiagao 2022-11-11 05:38:39 UTC
Hi German,
I tried to repoduce just under qemu kvm env, but didn't reproduce, I would list my steps.
1. start virtiofsd
[root@dell-per440-06 bbbbk]# /usr/libexec/virtiofsd -o source=/home/test  --socket-path=/tmp/sock1  --modcaps=+sys_admin &

2. start rhel920 guest.
     -chardev socket,id=char_virtiofs_fs,path=/tmp/sock1 \
     -device vhost-user-fs-pci,id=vufs_virtiofs_fs,chardev=char_virtiofs_fs,tag=myfs,queue-size=1024,bus=pcie-root-port-3,addr=0x0 \


3. in guest, mount the virtiofs
[root@bootp-73-75-109 mnt]#  mount -t virtiofs myfs mmm/

4. add a user and change it's group to wheel
 184  useradd u1
  185  passwd u1
  186  usermod -g wheel u1

5. switch to u1 user and try to mkdir on shared directory, it shows me 'Permission denied.' 
[root@bootp-73-75-109 mmm]# su u1
[u1@bootp-73-75-109 mnt]$ mkdir -m 0770 mmm/testdir
mkdir: cannot create directory ‘mmm/testdir’: Permission denied


So I failed on the step 1 in your #c0, I'm wondering what's the virtiofs cmd line do you have?

Thanks,
Xiaoling

Comment 2 German Maglione 2022-11-11 14:04:30 UTC
(In reply to xiagao from comment #1)
> Hi German,
> I tried to repoduce just under qemu kvm env, but didn't reproduce, I would
> list my steps.
> 1. start virtiofsd
> [root@dell-per440-06 bbbbk]# /usr/libexec/virtiofsd -o source=/home/test 
> --socket-path=/tmp/sock1  --modcaps=+sys_admin &
> 
> 2. start rhel920 guest.
>      -chardev socket,id=char_virtiofs_fs,path=/tmp/sock1 \
>      -device
> vhost-user-fs-pci,id=vufs_virtiofs_fs,chardev=char_virtiofs_fs,tag=myfs,
> queue-size=1024,bus=pcie-root-port-3,addr=0x0 \
> 
> 
> 3. in guest, mount the virtiofs
> [root@bootp-73-75-109 mnt]#  mount -t virtiofs myfs mmm/
> 
> 4. add a user and change it's group to wheel
>  184  useradd u1
>   185  passwd u1
>   186  usermod -g wheel u1
> 
> 5. switch to u1 user and try to mkdir on shared directory, it shows me
> 'Permission denied.' 
> [root@bootp-73-75-109 mmm]# su u1
> [u1@bootp-73-75-109 mnt]$ mkdir -m 0770 mmm/testdir
> mkdir: cannot create directory ‘mmm/testdir’: Permission denied
> 

Sorry for confusion, these command are intended to be run as root and the user
"u1" must have the wheel group as a supplementary, not as a main group.

> 
> So I failed on the step 1 in your #c0, I'm wondering what's the virtiofs cmd
> line do you have?

I updated the comment #0 with clearer instructions

Comment 3 xiagao 2022-11-14 10:23:42 UTC
Thanks German for your update.
I can reproduce then, the difference is the previous group is the main group, while the error occurred on the supplementary steps.

Thank you very much.

Comment 9 xiagao 2022-12-29 09:10:44 UTC
Test passed, so set bug status to verified.
1, create u1 and change it to the wheel group (as a supplementary group)
[root@bootp-73-75-32 mm]# useradd u1
[root@bootp-73-75-32 mm]# passwd u1
[root@bootp-73-75-32 mm]# usermod -G wheel u1

2. mkdir testdir and set rwx premission for owner and group.
[root@bootp-73-75-32 mm]# mkdir -m 0770 testdir
[root@bootp-73-75-32 mm]# chgrp wheel testdir
[root@bootp-73-75-32 mm]# ll
drwxrwx---. 2 root wheel    6 Dec 29 17:02 testdir

3. switch to u1 and try to create a file under testdir, it
[u1@bootp-73-75-32 mm]$ touch testdir/file
[u1@bootp-73-75-32 mm]$ ls -l testdir/file
-rw-r--r--. 1 u1 u1 0 Dec 29 17:02 testdir/file



pkg:
virtiofsd-1.5.0-1.el9.x86_64
qemu-kvm-7.2.0-1.el9
5.14.0-219.el9.x86_64(host)
5.14.0-226.el9.x86_64(guest)

Comment 11 errata-xmlrpc 2023-05-09 07:46:45 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (virtiofsd bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2334