Bug 1878813
Summary: | NFS with security_label does not list directory correctly | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jiri Konecny <jkonecny> | ||||
Component: | nfs-utils | Assignee: | Steve Dickson <steved> | ||||
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 32 | CC: | Bert.Deknuydt, bfields, rh-bugzilla, steved | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2020-09-15 14:29:20 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Jiri Konecny
2020-09-14 14:57:37 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. Does the problem sitll occur if the server is in permissive mode? 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. Created attachment 1714839 [details]
tcpdump trace
Contains two READDIR: first without "images" directory, second with.
name matters; e.g. renaming "images" to "image" shows full directory content. Renaming back shows the problem again. (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. probably a dup of https://bugzilla.redhat.com/show_bug.cgi?id=1873720 (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 *** |