Bug 1878813 - NFS with security_label does not list directory correctly
Summary: NFS with security_label does not list directory correctly
Keywords:
Status: CLOSED DUPLICATE of bug 1873720
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: 32
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-09-14 14:57 UTC by Jiri Konecny
Modified: 2020-09-15 14:29 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-15 14:29:20 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
tcpdump trace (16.95 KB, application/vnd.tcpdump.pcap)
2020-09-14 17:43 UTC, Enrico Scholz
no flags Details

Description Jiri Konecny 2020-09-14 14:57:37 UTC
Description of problem:

I have two servers both Fedora 32. One providing NFS and second is client for the NFS export. Client NFS is using this storage for libvirt so I want to have security labels stored on the NFS to avoid selinux issues.

Problem is that the client see just a few files (2 from about 30). However, the client can read all the files, can access all the files and add new files but does not see them by `ls` command. Not even files created by the client, however, they are successfully created on the second side.

I wasn't able to spot any pattern in what files could be see and what not. It's not security label, ACL or file permissions.

Export is a separate LV with XFS mount:

$ mount | grep virtuals_cobra05
/dev/mapper/vg_unsafe-virtuals_cobra05 on /mnt/virtuals_cobra05 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,sunit=1024,swidth=2048,noquota)

If I remove security_label from the export, client can see all the files without problem.


$ cat /etc/exports:
/mnt/virtuals_cobra05   *(rw,no_root_squash,sync,security_label) 


client listing:
$ ls nfs_cobra04/ | wc -l
7


without security label:
$ cat /etc/exports
/mnt/virtuals_cobra05   *(rw,no_root_squash,sync)

client listing:
$ ls nfs_cobra04/ | wc -l
58



Version-Release number of selected component (if applicable):
Both client - server have the same version:
nfs-utils-2.5.1-2.rc3.fc32.x86_64

kernel:
5.8.6-201.fc32.x86_64

How reproducible:
Always

Steps to Reproduce:
I'm able to reproduce this on my current machines but I don't know why this is happening. It wasn't the issue before upgrade of these machines to Fedora 32.

Actual results:
Don't see all the files on the client side. Even thought the files can be accessed.

Expected results:
Client should see all the files.

Comment 3 Jiri Konecny 2020-09-14 15:34:04 UTC
Right now I have workaround that my client machine have SELinux in permisive mode so no problem with libvirt that the security lables are missing. However, even without the listing libvirt worked with some warnings.


Also here is example how the file can be accessed.


$curl -OL https://kojipkgs.fedoraproject.org/compose/branched/Fedora-33-20200914.n.0/compose/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-33-20200914.n.0.iso

$ ls | grep Fedora-Everything-netinst-x86_64-33-20200914.n.0.iso
<nothing>

$ ls Fedora-Everything-netinst-x86_64-33-20200914.n.0.iso
Fedora-Everything-netinst-x86_64-33-20200914.n.0.iso

$ file Fedora-Everything-netinst-x86_64-33-20200914.n.0.iso
Fedora-Everything-netinst-x86_64-33-20200914.n.0.iso: DOS/MBR boot sector; partition 2 : ID=0xef, start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 164, 22468 sectors


As you can see direct ls for a file works but not listing from the directory.

Comment 4 J. Bruce Fields 2020-09-14 15:48:08 UTC
Does the problem sitll occur if the server is in permissive mode?

Comment 5 Enrico Scholz 2020-09-14 17:42:02 UTC
ditto here; happened after upgrade of kernel package on client.  E.g. 5.7.12 was ok, 5.8.7 is broken.   Server is CentOS 7.6.

Analyzing network traffic with wireshark shows that the `READDIR` response contains the full directory listing but client shows only a small subset.


It seems to be triggered by some files; e.g. 

1. I create a directory with files 'bar', 'foo' + 'xxx' on the server --> they are shown on the client too

[ensc@sinclair ~]$ ll -a  ~/net/tmp/test-1878813/ -Z
total 24
drwxrwxr-x.  3 ensc ensc unconfined_u:object_r:user_tmp_t:s0 12288 Sep 14 19:39 .
drwx------. 23 ensc ensc user_u:object_r:user_tmp_t:s0        4096 Sep 14 19:22 ..
drwxrwxr-x.  2 ensc ensc user_u:object_r:user_home_t:s0       4096 Sep 14 19:34 bar
-rw-rw-r--.  1 ensc ensc user_u:object_r:user_home_t:s0          0 Sep 14 19:33 foo
-rw-rw-r--.  1 ensc ensc system_u:object_r:user_home_t:s0     1212 Jun  3  2012 xxx


2. I copy such a file (here: "images" directory) --> listing shows only this directory

[ensc@sinclair ~]$ ll -a  ~/net/tmp/test-1878813/ -Z
total 20
drwxrwxr-x.  4 ensc ensc unconfined_u:object_r:user_tmp_t:s0 12288 Sep 14 19:40 .
drwx------. 23 ensc ensc user_u:object_r:user_tmp_t:s0        4096 Sep 14 19:22 ..
drwxrwxr-x.  3 ensc ensc user_u:object_r:user_home_t:s0       4096 Jan 28  2005 images



I will append a tcpdump trace.

Comment 6 Enrico Scholz 2020-09-14 17:43:38 UTC
Created attachment 1714839 [details]
tcpdump trace

Contains two READDIR: first without "images" directory, second with.

Comment 7 Enrico Scholz 2020-09-14 17:47:46 UTC
name matters; e.g. renaming "images" to "image" shows full directory content. Renaming back shows the problem again.

Comment 8 Jiri Konecny 2020-09-15 08:31:35 UTC
(In reply to J. Bruce Fields from comment #4)
> Does the problem sitll occur if the server is in permissive mode?

Yes, it is happening even when both server and client are set to permissive mode.

I did

server:
setenforce 0
vim /etc/exports
exportfs -av



client:
setenforce 0
umount <nfs_export>
mount <nfs_export>


Still the same outcome. I see just a few files.

Comment 9 Enrico Scholz 2020-09-15 09:34:19 UTC
probably a dup of https://bugzilla.redhat.com/show_bug.cgi?id=1873720

Comment 10 J. Bruce Fields 2020-09-15 14:29:20 UTC
(In reply to Enrico Scholz from comment #9)
> probably a dup of https://bugzilla.redhat.com/show_bug.cgi?id=1873720

Agreed.

*** This bug has been marked as a duplicate of bug 1873720 ***


Note You need to log in before you can comment on or make changes to this bug.