Created attachment 874438 [details] pcap file showing corrupt security label in READDIR response While testing with v4.2 this morning, I saw this warning pop up on the client: [ 2830.695503] nfs_setsecurity() ��stem_u:object_r:samba_share_t:s0 2 security_inode_notifysecctx() -22 ...a little debugging and I noticed that the server is sending a corrupt security label in its reply. See the READDIR reply frame in the attached pcap file. The corrupt entry is "rawhide.test". When I look at the directory on the server, I see: $ ls -ldZ rawhide.test/ drwxrwxr-x. jlayton jlayton system_u:object_r:unlabeled_t:s0 rawhide.test/ ...on the client, I see more or less the same thing. drwxrwxr-x. jlayton jlayton system_u:object_r:unlabeled_t:s0 /mnt/tlielax/rawhide.test ...I suspect it's not labeled properly on the server, but still should have the server send sane security labels in that situation.
The server's kernel in this case is: 3.13.6-200.fc20.x86_64 ...I haven't yet tested anything later.
Ok, I added a debug printk in nfsd4_encode_fattr, and saw this pop up in the logs: [ 202.064905] SELinux: Context \xfffffff7\xffffff94 is not valid (left unmapped). [ 202.064945] nfsd4_encode_fattr: err=0 ino=50332480 contextlen=2 ...so it seems like SELinux notices that the label is corrupt and throws that printk, but then it seems like it fills out the context buffers with that junk anyway. It seems like it ought to be filling it out with something like "system_u:object_r:unlabeled_t:s0". Dragging in Eric...can you get someone from your team to have a look at this? I assume this is likely a problem for RHEL7 too...
FWIW, this filesystem is a 20G XFS filesystem. I can try to do some sort of block-level clone of it if needed, but might need some guidance from the XFS folks...
No, I'd call this 'expected behavior' and/or NOTABUG Jeff explained that this file was created on the server almost certainly while he had the client bug which was scribbling random garbage into the label. The server, accepted the random garbage as an invalid label. Now the he enabled selinux on the client again, he is getting the invalid label back from the server and it isn't working very well :) Using restorecon on the client to fix and labels which were created while you have the client labeling bug should take care of the issue...
Further, Eric said this on IRC: "There was a decision made to allow invalid labels on the server, and to server them to the clients just the way they came in, to allow for clients which understand labels the server doesn't..." Given that, then it makes sense. I'll go ahead and close this as NOTABUG.