Bug 1478135 - Fedora 26 nfs server doesn't export SELinux file context labels
Summary: Fedora 26 nfs server doesn't export SELinux file context labels
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: 26
Hardware: Unspecified
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: 2017-08-03 16:32 UTC by Edgar Hoch
Modified: 2017-09-04 20:32 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-08-31 15:10:59 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Edgar Hoch 2017-08-03 16:32:57 UTC
Description of problem:

I use nfs export option selinux_label on our nfs server.

When running Fedora 25 on nfs server, it works as expected:
Nfs clients see the same SELinux file context label on remote nfs mounted file systems as it is set on nfs server.

But running Fedora 26 on nfs server, all files on remote nfs mounted file systems show SELinux file context label "nfs_t", NOT the label as set on on exported file system.

This is bad, because some applications requires correct SELinux labels.

I have tested with SELinux in permissive mode, but his hasn't changed the behavior.

I have tested nfs mounted partitions from nfs server with Fedora 25 and with Fedora 26 on a nfs client running Fedora 26: nfs partition from Fedora 25 server shows the right context labels, nfs partition from Fedora 26 only shows "nfs_t".

Do I something wrong? Has options changed? (I have not found any notes about a change.)

Fedora 26 should forward SELinux file context labels (with nfs vers=4.2) from nfs server to nfs client.



Version-Release number of selected component (if applicable):
nfs-utils-2.1.1-5.rc5.fc26.x86_64
kernel-4.11.11-300.fc26.x86_64


How reproducible:
Always

Steps to Reproduce:
1. Create a directory to export, for example /mnt/testpartition.
2. Create a directory and a file in it, for example
    mkdir /mnt/testpartition/testdir
    date > /mnt/testpartition/testdir/testdate.txt
3.  Set SELinux file context labels to a no-default value,
    so you can see if the default or the correct label is shown. Example:
    chcon -t usr_t /mnt/testpartition/testdir
    chcon -t var_t /mnt/testpartition/testdir/testdate.txt

3. Export a directory or file system using nfs export option security_label
  for example in file /etc/exports a line
/mnt/testpartition *:(rw,sync,security_label)
4. Start nfs server: systemctl start nfs

5. On another computer, nfs mount the exported file system from the nfs server.
   mkdir /mnt/nfstest
   mount nfsserver:/mnt/testpartition /mnt/nfstest

6. Check which SELinux file context labels are shown:
   ls -lZR /mnt/nfstest


Actual results:
If nfs server runs Fedora 26, then all nfs mounted labels are "nfs_t".
If nfs server runs Fedora 25, then nfs mounted labels are the same as on nfs server.

Expected results:
If nfs server runs Fedora 26, then nfs mounted labels are the same as on nfs server.

Additional info:
I don't know if nfs-utils is the right component. Please change it if you thing another component is right.

Comment 1 J. Bruce Fields 2017-08-07 15:40:16 UTC
(In reply to Edgar Hoch from comment #0)
> Has options changed? (I have not found any notes about a change.)

Yes, apologies, this should have been documented in release notes or somewhere.  SELinux labeling is still supported, but it is now off by default, and you now need to add the "security_label" option to any export for which you wish the server to support for security labels.

Having security labels on by default turned out to be a problem; see bug 1406885 for details.

Obviously we normally don't want to break working functionality on upgrade, but in this case we were stuck breaking either setups that depended on selinux or those for which the server labels didn't make sense, and the former seemed the lesser evil.

Closing under assumption this is indeed the issue you're hitting.  Adding the security_label export option, restarting the server, and remounting from the clients should resolve the problem.  If not, please reopen the bug.

Comment 2 Edgar Hoch 2017-08-07 19:34:12 UTC
Thanks for your answer. But export option "security_label" doesn't solve the problem.

I have already used export option "security_label" since a year (August 2016), I think I have added this option when I installed Fedora 24. It also works with Fedora 25. But on Fedora 26 it seems to be ignored.

In my "Steps to Reproduce:" you can see that I have already used "security_label".

Comment 3 J. Bruce Fields 2017-08-07 21:31:32 UTC
(In reply to Edgar Hoch from comment #2)
> In my "Steps to Reproduce:" you can see that I have already used
> "security_label".

Oops, thanks for the correction.

I can try to reproduce when I'm back at work in a couple weeks.

Till then, I think the next step would be to take a look at the network traffic.

So, start something like "tcpdump -s0 -wtmp.pcap -i<your ethernet address>", then reproduce the problem, then kill tcpdump and attach tmp.pcap to this bug.

And/or also take a look at tcpdump in wireshark yourself--first things we're looking for:

 - check the "minorversion" field in an NFSv4 compound to make sure it's 2.
 - look for GETATTRs of the "supported_attributes" field for filehandles in the relevant filesystem to see if the server's reporting support for the security label attribute.

Comment 4 Edgar Hoch 2017-08-25 01:26:11 UTC
It seems that the problem is solved by a newer kernel (currently running kernel-4.12.8-300.fc26.x86_64) - or by updates of other packages. I will upgrade other servers to Fedora 26 in the next two weeks and report if they works as expected.

Comment 5 Edgar Hoch 2017-08-31 15:10:59 UTC
I have installed other Fedora 26 nfs servers and SELinux labels are correctly available on nfs client. So the problem is solved; I cannot tell why, it seems that some of updated packages solved the problem.


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