Bug 984718

I believe the client will also need to be built with NFS_V4_2 and NFS_V4_SECURITY_LABEL, and then will need to mount with -ominorversion=2 (that can also be set in a configuration file--see the nfsmount.conf(5) man page).

This should all default to off for now.  And we should maybe document what our criteria are before really recommending people use it in production.

At a minimum, we should ensure we have consensus that the on-the-wire protocol is unlikely to change.

Sadly this means few people will use it.

Any reason the client and server are not negotiating this?

I should have been clearer: I agree that we should turn *on* all the build configuration.  It's just the run-time configuration that I think should be off by default for now.

Previously I don't think we've even accepted code upstream for NFS features till the RFC was published.  In this case this is a part of draft that's some distance from being published.  I don't think the particular piece we've implemented is controversial, but I'd still rather take this one step at a time.

So my preference for now would be

a) Turn on all the kernel config options so nobody needs to rebuild a kernel to enable labeled NFS.
b) Document how to turn on support on the client and server.
c) Warn that this is still experimental and (worst case) there's a small possibility that compatibility could be broken in future Fedora.

Basically, users should only have to do maybe a one-line configuration change on client and server, at which point clients will negotiate labeled NFS if it's available.

Do you think that would still be too high a bar for now?

And in a future version we'd turn it on by default so they wouldn't even have to do that.

No that is fine, as long as it can be changed to default in the future.

(Oh, and ignore my "-ominorversion=2" thing, that does the same as steved's "-ov4.2".  And I think you want an nfsmount.conf like

[NFSMount_Global_Options]
  Defaultvers=4.2

to tell the client to try to negotiate 4.2 by default if available.  I haven't tested that, and Defaultvers isn't documented in the man page, steved's the expert on that config file....)

(In reply to J. Bruce Fields from comment #1)
> I believe the client will also need to be built with NFS_V4_2 and
> NFS_V4_SECURITY_LABEL, and then will need to mount with -ominorversion=2
> (that can also be set in a configuration file--see the nfsmount.conf(5) man
> page).
> 
> This should all default to off for now.  And we should maybe document what
> our criteria are before really recommending people use it in production.
Looking the rawhide kernel config-generic file, it appears the 
code is enabled by default 
CONFIG_NFSD_V4_SECURITY_LABEL=y
CONFIG_NFS_V4_2=y

> 
> At a minimum, we should ensure we have consensus that the on-the-wire
> protocol is unlikely to change.
I'm thinking since user level changes (mount option and servers version changes) are needed to use this code... Its probably ok to leave the kernel 
configs on...

(In reply to Steve Dickson from comment #6)
> I'm thinking since user level changes (mount option and servers version
> changes) are needed to use this code... Its probably ok to leave the kernel 
> configs on...

Yes, agreed.

FESCo pointed me at this bug today because nobody from the Fedora kernel team is CC'd.  We should avoid that in the future.

For F20 (and rawhide) the kernel config options are still enabled.  Per comment #7, that seems to be OK because nobody can actually use them until nfs-utils is updated.  Is that a correct summary?

If so, I can leave them on but if they are going to cause some issues I'd like to disable them.

Going forward, what are the plans for nfs-utils here?  If it is going to be updated for F20 then we'd need to coordinate a bit.

Josh my understanding is that you can use labeled NFS now, you just have to specify the client and server side your self in the nfs-utils.  They have not built any retry into the protocol yet.  

So in order to get this to work, I need to specify mount -t nfs4.2 or something like this.  And on the server side I need to edit some config to say the server supports labeled nfs 4.2 protocol.

(In reply to Josh Boyer from comment #8)
> FESCo pointed me at this bug today because nobody from the Fedora kernel
> team is CC'd.  We should avoid that in the future.
> 
> For F20 (and rawhide) the kernel config options are still enabled.  Per
> comment #7, that seems to be OK because nobody can actually use them until
> nfs-utils is updated.  Is that a correct summary?

Actually they just need to change a config file or two.

> If so, I can leave them on but if they are going to cause some issues I'd
> like to disable them.

It's opt-in, so issues will be restricted to people that explicitly ask for the new stuff.

> Going forward, what are the plans for nfs-utils here?  If it is going to be
> updated for F20 then we'd need to coordinate a bit.

The only future change here is that eventually we expect to default this to on.  I don't know when that will be.  It will be a trivial change, and transparent to the user.  (Clients and servers automatically negotiate the maximum mutually supported NFS version, so there should be no backwards compatibility issues.)

I don't think there will be any special coordination required.

It might be worth a line in the release notes ("NFS now selinux-enabled!") whenever we decide the feature has reached sufficient maturity to merit it.

(In reply to J. Bruce Fields from comment #10)
> (In reply to Josh Boyer from comment #8)
> > FESCo pointed me at this bug today because nobody from the Fedora kernel
> > team is CC'd.  We should avoid that in the future.
> > 
> > For F20 (and rawhide) the kernel config options are still enabled.  Per
> > comment #7, that seems to be OK because nobody can actually use them until
> > nfs-utils is updated.  Is that a correct summary?
> 
> Actually they just need to change a config file or two.

Ah, ok.

> > If so, I can leave them on but if they are going to cause some issues I'd
> > like to disable them.
> 
> It's opt-in, so issues will be restricted to people that explicitly ask for
> the new stuff.

Fedora is great at finding people like that :).  From the kernel side of things, I'm happy to leave the config options enabled and let people manually try it.

> > Going forward, what are the plans for nfs-utils here?  If it is going to be
> > updated for F20 then we'd need to coordinate a bit.
> 
> The only future change here is that eventually we expect to default this to
> on.  I don't know when that will be.  It will be a trivial change, and
> transparent to the user.  (Clients and servers automatically negotiate the
> maximum mutually supported NFS version, so there should be no backwards
> compatibility issues.)

FESCo pointed me to it because it's a Change targeted for F20.  This bug is still against rawhide, which would be F21 at this point.  If you don't think this is really ready to be default today, then perhaps you should inform FESCo you're now targeting F21.

I say today but F20 went into Alpha freeze yesterday, so technically any config file changes made to make it default needed to happen yesterday.  They'll require an exception and an update through bodhi at this point.

> I don't think there will be any special coordination required.

OK.

(In reply to Josh Boyer from comment #11)
> FESCo pointed me to it because it's a Change targeted for F20.  This bug is
> still against rawhide, which would be F21 at this point.  If you don't think
> this is really ready to be default today, then perhaps you should inform
> FESCo you're now targeting F21.
> 
> I say today but F20 went into Alpha freeze yesterday, so technically any
> config file changes made to make it default needed to happen yesterday. 
> They'll require an exception and an update through bodhi at this point.

I don't know when we want to default this to on, but it won't be for F20.

At this point (assuming F20 is at least 3.11-based) it's got the optional/experimental labeled NFS support, and I think that's all we need for now.

I'm ignorant of the process, but perhaps we want to leave this opened just till the selinux people get a chance to try out the experimental stuff in F20 and verify it's there and working?  And then we should close this as done, and open a new bug later if necessary to change defaults and/or advertise the feature more widely.

(In reply to J. Bruce Fields from comment #12)
> (In reply to Josh Boyer from comment #11)
> > FESCo pointed me to it because it's a Change targeted for F20.  This bug is
> > still against rawhide, which would be F21 at this point.  If you don't think
> > this is really ready to be default today, then perhaps you should inform
> > FESCo you're now targeting F21.
> > 
> > I say today but F20 went into Alpha freeze yesterday, so technically any
> > config file changes made to make it default needed to happen yesterday. 
> > They'll require an exception and an update through bodhi at this point.
> 
> I don't know when we want to default this to on, but it won't be for F20.
> 
> At this point (assuming F20 is at least 3.11-based) it's got the
> optional/experimental labeled NFS support, and I think that's all we need
> for now.
> 
> I'm ignorant of the process, but perhaps we want to leave this opened just
> till the selinux people get a chance to try out the experimental stuff in
> F20 and verify it's there and working?  And then we should close this as
> done, and open a new bug later if necessary to change defaults and/or
> advertise the feature more widely.

That sounds fine.  I think the only additional thing you need to from a process perspective is move https://fedoraproject.org/wiki/Changes/LabeledNFS to F21.  Jaroslav can help you with that.

Josh, thanks for asking right questions in the right place. As this means, with some chance, we will get some experimental support in F20, and proper implementation in F21 (that would deserve release notes coverage etc.), I'll move Change to F21 in the tracking bug. Please, follow up with me when F21 Changes acceptance process will be initiated.

Well we I finally began testing yesterday and actually would like to schedule a test day for this "Change", to figure out what works and does not work.  

We are going to need to document this, perhaps in more then a release note.  Since there are many combinations.

Currently it is working pretty well but is a bit of a pain for the user to setup.  Have to edit config on the server and run with a -o v4.2 on the client.

(In reply to Daniel Walsh from comment #15)
> Currently it is working pretty well but is a bit of a pain for the user to
> setup. Have to edit config on the server and run with a -o v4.2 on the
> client.

For the client side configuration, see also comment #5.  We could consider documenting that instead of (or in addition to) the mount option, if you think it would be more convenient.

This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20

I had originally reported this to the Linux NFS Mailing List <linux-nfs.org> in March without receiving a response.  I continue to have the issue where upon initial mount, the client often mounts the /home dir with unlabeled_t.

On Saturday, March 22, 2014 01:43:47 AM Anthony Messina wrote:
> On Tuesday, March 11, 2014 01:41:49 PM Anthony Messina wrote:
> > I've begun testing out the labeled NFSv4.2 features with good success
> > with 
> > only one exception so far.  I have several workstations that use NFSv4.2 
> > mounted /home directories.  I've been able to remove the SELinux boolean 
> > requirement for 'use_nfs_home_dirs', however, on *one* of these
> > workstations,  the /home directory is labeled 'unlabeled_t' after boot
> > when
> > it should be labeled with 'home_root_t'.  This problem causes failures, as
> > you can imagine.
> >
> > 
> >
> > I mount the filesystem on all of the workstations in the same manner:
> > # /etc/fstab
> > ...
> > server.com:/home /home nfs rw,minorversion=2,sec=krb5p,x-systemd.automount
> > 0 0
> >
> > 
> >
> > Yet the issue occurs on only *one* workstation.  If I manually issue
> >
> > 
> >
> > chcon -t home_root_t /home
> >
> > 
> >
> > then I am able to login and use the system without issue.
> >
> > 
> >
> > All of the servers and workstations are using
> >
> > 
> >
> > kernel-3.13.6-200.fc20.x86_64
> > nfs-utils-1.2.9-3.0.fc20.x86_64
> >
> > 
> >
> > I realize this is not the SELinux mailing list, but I was wondering if
> > anyone  had any pointers on how to investigate this issue.  The
> > workstations are all nearly identical in configuration with the exception
> > of a few user-based differences such as GnuCash on one, but not the other,
> > etc.
> 
> While I haven't yet found a solution to this problem, I am able to confirm 
> that I now see this other workstations and it appears that it may be some
> sort  of race condition between the two mounts in the clients' fstab since
> it doesn't always occur on every workstation.  Perhaps someone can help me
> spot a problem in the following server or client configuration.
> 
> My single NFS server has the following in /etc/exports:
> 
> /export         2001:123:456:789::/64(fsid=0,crossmnt,sec=krb5p:krb5i) \
>                 10.1.1.0/24(fsid=0,crossmnt,sec=krb5p:krb5i)
> /export/home    2001:123:456:789::/64(rw,sec=krb5p) \
>                 10.1.1.0/24(rw,sec=krb5p)
> /export/media   2001:123:456:789::/64(rw,sec=krb5p:krb5i) \
>                 10.1.1.0/24(rw,sec=krb5p:krb5i)
> /export/software        2001:123:456:789::/64(rw,sec=krb5p:krb5i) \
>                         10.1.1.0/24(rw,sec=krb5p:krb5i)
> 
> And the following bind mounts in /etc/fstab:
> 
> /home           /export/home            none    bind    0 0
> /srv/media      /export/media           none    bind    0 0
> /srv/software   /export/software        none    bind    0 0
> 
> 
> And the following labels for the exported filesystems:
> 
> ~]# ls -lZ /
> drwxr-xr-x. root  root    system_u:object_r:home_root_t:s0 home
> 
> ~]# ls -lZ /srv
> drwxr-x---. auser agroup  system_u:object_r:public_content_rw_t:s0 media
> drwxr-x---. auser family  system_u:object_r:public_content_rw_t:s0 software
> 
> ~]# ls -lZ /export
> drwxr-xr-x. root  root    system_u:object_r:home_root_t:s0 home
> drwxr-x---. auser agroup  system_u:object_r:public_content_rw_t:s0 media
> drwxr-x---. auser family  system_u:object_r:public_content_rw_t:s0 software
> 
> 
> The clients mount the exports via the following in /etc/fstab
> 
> server.com:/home /home nfs rw,minorversion=2,sec=krb5p,x-systemd.automount 0
> 0 server.com:/ /mnt/srv  nfs
> rw,minorversion=2,sec=krb5i,x-systemd.automount 0 0
> 
> Again, the issue is that the /home mount on the clients tends to be mounted
> as  "unlabeled_t" which causes failures with SELinux enabled.
> 
> Is there an issue in the way I'm exporting things that may cause this?

Nothing jumps out at me as wrong.

Is it possible there could be some kind of startup race on the server side that allows the server to work with /export before the bind mounts are done?

Watching the client<->server traffic in wireshark might help confirm whether the problem is client- or server- side.  (There should be a GETATTR request for the security label on /home at some point--what does it return?)

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.