View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0018013 | CentOS-7 | kernel | public | 2021-01-13 14:50 | 2021-01-14 10:01 |
Reporter | cmdntrf | ||||
Priority | normal | Severity | minor | Reproducibility | always |
Status | assigned | Resolution | open | ||
Product Version | 7.9.2009 | ||||
Target Version | Fixed in Version | ||||
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 | |||||
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) |
|
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) |
|