Re: [PATCH] selinux: Fix SBLABEL_MNT for NFS mounts

From	"J. Bruce Fields" <bfields@redhat.com>
Newsgroups	linux.kernel
Subject	Re: [PATCH] selinux: Fix SBLABEL_MNT for NFS mounts
Date	2017-04-05 01:30 +0200
Message-ID	<tsG3D-35P-7@gated-at.bofh.it> (permalink)
References	(1 earlier) <tqttV-4o9-39@gated-at.bofh.it> <tqD0e-2Ug-11@gated-at.bofh.it> <tqM3w-1dT-11@gated-at.bofh.it> <tqMmS-1rG-21@gated-at.bofh.it> <tqMwy-1vj-15@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Thu, Mar 30, 2017 at 01:52:14PM -0400, Stephen Smalley wrote:
> On Thu, 2017-03-30 at 13:41 -0400, J. Bruce Fields wrote:
> > It is.  I also want to keep new protocol upgrades free of user
> > regressions, which the 4.1->4.2 upgrade is in most cases if we turn
> > on
> > security labeling by default.  So I was stuck choosing between two
> > regresisons, and figured 4.2 user depending on security labeling was
> > still the much rarer case.
> > 
> > So I'd like to keep security labeling off by default, but if there's
> > anything I can do to smooth the transition obviously that's good.
> 
> Yes, I understand - wish though that it could have been communicated
> better, e.g. on selinux list (unless I just missed it somehow).

No, I didn't think of it, apologies, I agree that would have been
smarter.

> > > and at the very least, it seems odd that they didn't just use
> > > "seclabel" as the kernel does in /proc/mounts to signify a
> > > filesystem
> > > that supports security labeling by userspace.
> > 
> > I see logic in sb_finish_set_opts() that sets SBLABEL_MNT in the
> > selinux_is_sblabel_mnt() case.  Doesn't that mean "seclabel" shows up
> > in
> > /proc/mounts when we nfs sets SECURITY_LSM_NATIVE_LABELS?
> > 
> > I may not understand your comment, I'm pretty unfamiliar with this
> > area.
> 
> Correct, I just meant it seems potentially confusing to users to use
> "security_label" in exports when we show it as "seclabel" in
> /proc/mounts.  I know, they are totally different namespaces (in the
> conventional sense), but consistency might have been more user-
> friendly.

Oh, got it.

We've had problems when NFS client mount and server export options are
spelled the same but have subtle differences in semantics (I'm thinking
of "async").  But maybe that wouldn't have been an issue here.

--b.

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

[PATCH] selinux: Fix SBLABEL_MNT for NFS mounts Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2017-03-29 17:30 +0200
  Re: [PATCH] selinux: Fix SBLABEL_MNT for NFS mounts "J. Bruce Fields" <bfields@redhat.com> - 2017-03-29 23:40 +0200
    Re: [PATCH] selinux: Fix SBLABEL_MNT for NFS mounts Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2017-03-30 09:50 +0200
      Re: [PATCH] selinux: Fix SBLABEL_MNT for NFS mounts Stephen Smalley <sds@tycho.nsa.gov> - 2017-03-30 19:30 +0200
        Re: [PATCH] selinux: Fix SBLABEL_MNT for NFS mounts "J. Bruce Fields" <bfields@redhat.com> - 2017-03-30 19:50 +0200
          Re: [PATCH] selinux: Fix SBLABEL_MNT for NFS mounts Stephen Smalley <sds@tycho.nsa.gov> - 2017-03-30 20:00 +0200
            Re: [PATCH] selinux: Fix SBLABEL_MNT for NFS mounts "J. Bruce Fields" <bfields@redhat.com> - 2017-04-05 01:30 +0200

csiph-web