virtiofsd passes through xattrs by default. The trusted.* xattr prefix requires CAP_SYS_ADMIN. This capability is not available when virtiofsd is running in a container. Another solution is needed for trusted.* xattrs such as prefixing xattr names with a string. Other userspace file system servers have implemented similar solutions although there is no standard prefix that is supported by all of them.
Posted v2 of my mapping patch: https://www.redhat.com/archives/virtio-fs/2020-August/msg00112.html
Hi David, I would like to confirm with you if this bug an RFE bug, if yes, can we add RFE keyword? Thanks, Xiaoling
Xiaoling: I think it is an RFE, but we may well have other bz's dependent on it; so it might be more urgent than just a random RFE.
Posted v3 of my mapping patch: https://lists.gnu.org/archive/html/qemu-devel/2020-10/msg04146.html
In upstream 6084633dff3a05d63176^..1d84a0213a2ec7094abe you can use the -o xattrmap options to remap xattr naming between client and server.
*** Bug 1849147 has been marked as a duplicate of this bug. ***
We are checking RFE bug on RHEL8.4, so I have some questions to confirm with you. Thanks in advance. 1. Could you give me some test information,how should I test this in the future? The following is the steps I list,please feel free to correct it. Here is the steps I list: 1. Drop cap_sys_admin # capsh --print Current: = cap_chown,cap_dac_override,cap_dac_read_search,..... # capsh --drop=cap_sys_admin -- # capsh --print (confirm cap_sys_admin dropped successfully ) 2. Run the virtiofsd daemon on the host e.g: # /usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu -o source=/tmp/virtiofs_test -o cache=auto 3. Boot a guest on the host. e.g: # /usr/libexec/qemu-kvm ... -smp 8 \ -m 4G \ -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on \ -numa node,memdev=mem \ -chardev socket,id=char0,path=/tmp/vhostqemu \ -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=myfs \ ...
(In reply to menli from comment #11) > We are checking RFE bug on RHEL8.4, so I have some questions to confirm with > you. Thanks in advance. > 1. Could you give me some test information,how should I test this in the > future? The following is the steps I list,please feel free to correct it. > > > Here is the steps I list: > > 1. Drop cap_sys_admin > > # capsh --print > Current: = cap_chown,cap_dac_override,cap_dac_read_search,..... > # capsh --drop=cap_sys_admin -- > # capsh --print (confirm cap_sys_admin dropped successfully ) > > > 2. Run the virtiofsd daemon on the host > e.g: > # /usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu -o > source=/tmp/virtiofs_test -o cache=auto > > 3. Boot a guest on the host. > e.g: > # /usr/libexec/qemu-kvm > ... > -smp 8 \ > -m 4G \ > -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on \ > -numa node,memdev=mem \ > -chardev socket,id=char0,path=/tmp/vhostqemu \ > -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=myfs \ > ... 4 Mount the filesystem in the guest: mount -t virtiofs myfs /mnt 5 Check you can write something into the mount (inside guest) touch /mnt/anewfile 6) Check it appears outside (on host) ls -l /tmp/virtiofs_test/anewfile
(In reply to Dr. David Alan Gilbert from comment #12) > (In reply to menli from comment #11) > > We are checking RFE bug on RHEL8.4, so I have some questions to confirm with > > you. Thanks in advance. > > 1. Could you give me some test information,how should I test this in the > > future? The following is the steps I list,please feel free to correct it. > > > > > > Here is the steps I list: > > > > 1. Drop cap_sys_admin > > > > # capsh --print > > Current: = cap_chown,cap_dac_override,cap_dac_read_search,..... > > # capsh --drop=cap_sys_admin -- > > # capsh --print (confirm cap_sys_admin dropped successfully ) > > > > > > 2. Run the virtiofsd daemon on the host > > e.g: > > # /usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu -o > > source=/tmp/virtiofs_test -o cache=auto > > > > 3. Boot a guest on the host. > > e.g: > > # /usr/libexec/qemu-kvm > > ... > > -smp 8 \ > > -m 4G \ > > -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on \ > > -numa node,memdev=mem \ > > -chardev socket,id=char0,path=/tmp/vhostqemu \ > > -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=myfs \ > > ... > > 4 Mount the filesystem in the guest: > mount -t virtiofs myfs /mnt > > 5 Check you can write something into the mount > (inside guest) touch /mnt/anewfile > > 6) Check it appears outside > (on host) ls -l /tmp/virtiofs_test/anewfile Thanks for your correction~
reproduce this issue on build qemu-kvm-5.1.0-15.module+el8.3.1+8772+a3fdeccd.x86_64 with step like comment 11 after step3 the result is: [root@dell-per440-02 test]# /usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu -o source=/dev/shm/ -o cache=none --thread-pool-size=1 -o log_level=debug [861433172851963] [ID: 01176067] virtio_session_mount: Waiting for vhost-user socket connection... [861437886377712] [ID: 01176067] virtio_session_mount: Received vhost-user socket connection [861437886530499] [ID: 01176067] unshare(CLONE_NEWPID | CLONE_NEWNS): Operation not permitted test on build qemu-kvm-block-gluster-5.2.0-1.module+el8.4.0+9091+650b220a.x86_64 the result is following, so could you please check if this issue fixed in this build ? thanks [root@dell-per730-47 ~]# /usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu -o source=/dev/shm/ -o cache=none --thread-pool-size=1 -o log_level=debug [781473902976] [ID: 00002822] virtio_session_mount: Waiting for vhost-user socket connection... [787287985082] [ID: 00002822] virtio_session_mount: Received vhost-user socket connection [787288097981] [ID: 00002822] unshare(CLONE_NEWPID | CLONE_NEWNS): Operation not permitted
Yes, patch mentioned as fix is present in the build.
reproduce this issue on build qemu-kvm-5.1.0-15.module+el8.3.1+8772+a3fdeccd.x86_64 with step like comment 12 after step3 the result is: [root@dell-per440-02 test]# /usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu -o source=/dev/shm/ -o cache=none --thread-pool-size=1 -o log_level=debug [861433172851963] [ID: 01176067] virtio_session_mount: Waiting for vhost-user socket connection... [861437886377712] [ID: 01176067] virtio_session_mount: Received vhost-user socket connection [861437886530499] [ID: 01176067] unshare(CLONE_NEWPID | CLONE_NEWNS): Operation not permitted Test on build qemu-kvm-block-gluster-5.2.0-1.module+el8.4.0+9091+650b220a.x86_64 with step like comment 12 , the result is the same as above, so could you please help check my steps again? if my steps are okay, could you help check this issue again , thanks
for the similar Bug 1910205 - Adding trusted.* xattr on virtiofs returns "Operation not permitted" reported again,so it should still be broken like comment18, I change the bug status to 'ASSIGEND' for now.
Hi David, if this bug is still target for rhel840 ? And could you please set ITM according to your plan? Thanks Menghuan
We actually have everything we need already, we just need to pass some extra flags: qemu-kvm-5.2.0-4.module+el8.4.0+9676+589043b9.x86_64.rpm # capsh --drop=cap_sys_admin -- # capsh --print (Shows we don't have cap_sys_admin) # /usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu -o source=/home/linux start qemu, and try and mount and that fails with: unshare(CLONE_NEWPID | CLONE_NEWNS): Operation not permitted so we need to tell it to use -o sandbox=chroot which doesn't need admin: /usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu -o source=/home/linux -o sandbox=chroot that now lets us mount the filesystem in the guest, using stefan's new sandboxing scheme. So now getting back to the original problem: guest# setfattr -n trusted.test /mnt/anexistingfile setfattr: /mnt/Makefile: Operation not supported /usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu -o source=/home/linux -o sandbox=chroot -o xattr still not supported So we need an extra parameter: # /usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu -o source=/home/linux -o sandbox=chroot -o xattr -o xattrmap=':map::user.virtiofsd.:' and now it works: [root@L1 ~]# setfattr -n trusted.test /mnt/Makefile [root@L1 ~]# [root@L1 ~]# getfattr -m '' /mnt/Makefile getfattr: Removing leading '/' from absolute path names # file: mnt/Makefile trusted.test so we've apparently set a trusted. xattr even though the virtiofsd doesn't have the cap_sys_admin on host: [root@virtlab720 home]# getfattr linux/Makefile # file: linux/Makefile user.virtiofsd.trusted.test because it's been translated to a user. xattr. So with those instructions, I think back to ON_QA
menli: I've set the ITM, since actually it's all there - it just needs testing with the details as comment 24.
*** Bug 1910205 has been marked as a duplicate of this bug. ***
(In reply to Dr. David Alan Gilbert from comment #24) > We actually have everything we need already, we just need to pass some extra > flags: > > qemu-kvm-5.2.0-4.module+el8.4.0+9676+589043b9.x86_64.rpm > > # capsh --drop=cap_sys_admin -- > # capsh --print > (Shows we don't have cap_sys_admin) > # /usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu -o source=/home/linux > > start qemu, and try and mount and that fails with: > > unshare(CLONE_NEWPID | CLONE_NEWNS): Operation not permitted > > so we need to tell it to use -o sandbox=chroot which doesn't need admin: > > /usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu -o source=/home/linux -o > sandbox=chroot > > that now lets us mount the filesystem in the guest, using stefan's new > sandboxing scheme. > > So now getting back to the original problem: > > guest# setfattr -n trusted.test /mnt/anexistingfile > setfattr: /mnt/Makefile: Operation not supported > > /usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu -o source=/home/linux -o > sandbox=chroot -o xattr > still not supported > > So we need an extra parameter: > # /usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu -o source=/home/linux > -o sandbox=chroot -o xattr -o xattrmap=':map::user.virtiofsd.:' > > and now it works: > > [root@L1 ~]# setfattr -n trusted.test /mnt/Makefile > [root@L1 ~]# > [root@L1 ~]# getfattr -m '' /mnt/Makefile > getfattr: Removing leading '/' from absolute path names > # file: mnt/Makefile > trusted.test > > so we've apparently set a trusted. xattr even though the virtiofsd doesn't > have the cap_sys_admin > > on host: > [root@virtlab720 home]# getfattr linux/Makefile > # file: linux/Makefile > user.virtiofsd.trusted.test > > because it's been translated to a user. xattr. > > So with those instructions, I think back to ON_QA Hi David, Thanks for help confirm this Test on rhel840, Works for me with the steps you list on comment 24 pkg: qemu-kvm-5.2.0-4.module+el8.4.0+9676+589043b9.x86_64 BTW, 1. Are there some windows cmd which similar with setfattr/getfattr , I want to repeat above steps with a windows guest, but not find related cmd, thanks in advance. 2. we will add related polarion case according to this bug, whether I can use the steps you list on comment 24 (add the steps 4-6 on comment 12)?
(In reply to menli from comment #29) > (In reply to Dr. David Alan Gilbert from comment #24) > > We actually have everything we need already, we just need to pass some extra > > Hi David, Thanks for help confirm this > > Test on rhel840, Works for me with the steps you list on comment 24 > pkg: > qemu-kvm-5.2.0-4.module+el8.4.0+9676+589043b9.x86_64 Great. > > BTW, > 1. Are there some windows cmd which similar with setfattr/getfattr , I want > to repeat above steps with a windows guest, but not find related cmd, thanks > in advance. I don't know Windows well; you could try asking Gal Hammer. > 2. we will add related polarion case according to this bug, whether I can > use the steps you list on comment 24 (add the steps 4-6 on comment 12)? Sure.
(In reply to Dr. David Alan Gilbert from comment #30) > (In reply to menli from comment #29) > > (In reply to Dr. David Alan Gilbert from comment #24) > > > We actually have everything we need already, we just need to pass some extra > > > > > Hi David, Thanks for help confirm this > > > > Test on rhel840, Works for me with the steps you list on comment 24 > > pkg: > > qemu-kvm-5.2.0-4.module+el8.4.0+9676+589043b9.x86_64 > > Great. > > > > > BTW, > > 1. Are there some windows cmd which similar with setfattr/getfattr , I want > > to repeat above steps with a windows guest, but not find related cmd, thanks > > in advance. > > I don't know Windows well; you could try asking Gal Hammer. Thanks, will change to verify after I try with a windows guest. > > 2. we will add related polarion case according to this bug, whether I can > > use the steps you list on comment 24 (add the steps 4-6 on comment 12)? > > > Sure.
reproduce this issue as comment14 After confirm with Gal， No extended attributes (file steams) in virtio-fs for windows, so for windows just verify guest can boot normally with " -o sandbox=chroot -o xattr -o xattrmap=':map::user.virtiofsd.:'" without cap_sys_admin Verified with qemu-kvm-5.2.0-4.module+el8.4.0+9676+589043b9.x86_64 on linux guest(steps same as comment24), the result as expected. So this issue is fixed, change status to verified.
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 (virt:av 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-2021:2098
*** Bug 2066778 has been marked as a duplicate of this bug. ***