0018013: ls does not display some files on NFS 4.2 mount when SELinux labels are exported - CentOS Bug Tracker

ID	Project	Category	View Status	Date Submitted	Last Update

0018013	CentOS-7	kernel	public	2021-01-13 14:50	2021-02-02 19:16

Reporter	cmdntrf	Assigned To
Priority	normal	Severity	minor	Reproducibility	always
Status	resolved	Resolution	fixed
Product Version	7.9.2009

Summary	0018013: ls does not display some files on NFS 4.2 mount when SELinux labels are exported
Description	I have an NFS 4.2 export of /home with security label export enabled. When users create a file in their home directory, it does not show up in ls output unless they refer explictly to the file by its name. The problem was introduced in kernel 3.10.0-1160.11.1.el7 and does not affect CentOS 8.
Steps To Reproduce	On an instance with SELinux enabled: # Create a centos user if missing: sudo useradd centos # Export /home cat << EOF \| sudo tee /etc/exports /home 127.0.0.1(rw,sync,root_squash,no_all_squash,security_label) EOF sudo systemctl start nfs-server # Mount the export locally sudo mkdir -p /mnt/nfs/home sudo mount -t nfs localhost:/home /mnt/nfs/home/ -o vers=4.2 # Create a new file sudo -u centos touch /mnt/nfs/home/centos/test # File is missing from ls output sudo -u centos ls -laZ /mnt/nfs/home/centos/ # File exist if refer by name sudo -u centos ls -laZ /mnt/nfs/home/centos/test
Additional Information	In kernel 3.10.0-1160.11.1.el7, the following patch was applied to fix a problem with nfs getxattr: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b4487b93545214a9db8cbf32e86411677b0cca21 Reverting the patch and recompiling the kernel without it successfully fixed the issue, ls then displayed all files in the user's home. I have narrowed down the issue to the patch of fs/nfs/nfs4xdr.c. I have added the following printk call after the "if (label->len < len) {" : printk(KERN_WARNING "%s: label too long (%u < %u)!\n", __func__, label->len, len); The printk returned the following output when calling ls: decode_attr_security_label: label too long (36 < 37)! Therefore it appears the label is one byte too long and the function returns instead of copying the label successfully.
Tags	No tags attached.

abrt_hash
URL

toracat 2021-01-14 09:56 manager ~0038174	It looks like the issue has been fixed upstream (kernel.org) by : commit d33030e2ee3508d65db5644551435310df86010e Author: Jeffrey Mitchell <jeffrey.mitchell@starlab.io> Date: Tue Sep 15 16:42:52 2020 -0500 nfs: Fix security label length not being reset nfs_readdir_page_filler() iterates over entries in a directory, reusing the same security label buffer, but does not reset the buffer's length. This causes decode_attr_security_label() to return -ERANGE if an entry's security label is longer than the previous one's. This error, in nfs4_decode_dirent(), only gets passed up as -EAGAIN, which causes another failed attempt to copy into the buffer. The second error is ignored and the remaining entries do not show up in ls, specifically the getdents64() syscall. Reproduce by creating multiple files in NFS and giving one of the later files a longer security label. ls will not see that file nor any that are added afterwards, though they will exist on the backend. In nfs_readdir_page_filler(), reset security label buffer length before every reuse Signed-off-by: Jeffrey Mitchell <jeffrey.mitchell@starlab.io> Fixes: b4487b935452 ("nfs: Fix getxattr kernel panic and memory overflow") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c index e732580..cb52db9 100644 --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -579,6 +579,9 @@ int nfs_readdir_page_filler(nfs_readdir_descriptor_t *desc, struct nfs_entry xdr_set_scratch_buffer(&stream, page_address(scratch), PAGE_SIZE); do { + if (entry->label) + entry->label->len = NFS4_MAXLABELLEN; + status = xdr_decode(desc, entry, &stream); if (status != 0) { if (status == -EAGAIN)

toracat 2021-01-14 10:01 manager ~0038175	The issue was reported for Fedora : https://bugzilla.redhat.com/show_bug.cgi?id=1873720 I cloned it for RHEL-7 : https://bugzilla.redhat.com/show_bug.cgi?id=1916129 (private, like all other RHEL kernel bugs)

toracat 2021-01-23 09:34 manager ~0038190	According to Red Hat, this issue is being worked on: https://bugzilla.redhat.com/show_bug.cgi?id=1917504 https://access.redhat.com/solutions/5708781 I think the patch will be in the next kernel update.

toracat 2021-02-02 00:43 manager ~0038217	The fix will be in kernel-3.10.0-1160.15.2.el7.

toracat 2021-02-02 19:16 manager ~0038218	The patch is in kernel-3.10.0-1160.15.2.el7 released today.

Date Modified	Username	Field	Change
2021-01-13 14:50	cmdntrf	New Issue
2021-01-13 22:29	toracat	Status	new => acknowledged
2021-01-14 09:56	toracat	Note Added: 0038174
2021-01-14 10:01	toracat	Status	acknowledged => assigned
2021-01-14 10:01	toracat	Note Added: 0038175
2021-01-23 09:34	toracat	Note Added: 0038190
2021-02-02 00:43	toracat	Note Added: 0038217
2021-02-02 19:16	toracat	Note Added: 0038218
2021-02-02 19:16	toracat	Status	assigned => resolved
2021-02-02 19:16	toracat	Resolution	open => fixed