linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Andreas Gruenbacher <agruenba@redhat.com>
Cc: Lu Xinyu <luxy.fnst@cn.fujitsu.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	fnst-xmlinux@cn.fujitsu.com
Subject: Re: SGID loss with nfsv3
Date: Tue, 15 May 2018 18:05:59 -0400	[thread overview]
Message-ID: <20180515220559.GD8178@fieldses.org> (raw)
In-Reply-To: <CAHc6FU5G2Y=H3C_YG7aASybzEfKrAuWRZFw-YoZuSw2i84qrag@mail.gmail.com>

On Tue, May 15, 2018 at 11:47:10PM +0200, Andreas Gruenbacher wrote:
> Hi Bruce,
> 
> On 15 May 2018 at 22:42, J. Bruce Fields <bfields@fieldses.org> wrote:
> > Ugh, resending with Andreas's address spelled correctly.
> >
> > On Tue, May 15, 2018 at 04:41:47PM -0400, J. Bruce Fields wrote:
> >> Looking at the problem more closely....
> >>
> >> So the desired behavior is that the SGID bit gets cleared on an explicit
> >> set of the acl, but not when the acl is merely inherited as part of file
> >> creation?
> 
> ideally yes, but that's not achievable over NFSv3, only over NFSv4.
> 
> >> If I understand correctly, in the NFSv3 case default acl inheritance is
> >> done manually by the client, which queries the default acl, calculates
> >> the inherited acl itself, and applies the result to the new file using a
> >> setacl call to the server.
> >>
> >> The server isn't capable of distinguishing this setacl call from any
> >> other setacl call, so can't know that it should skip clearing the SGID
> >> bit.
> >>
> >> Andreas, do I have that right?  Is this fixable?
> 
> Yes, I believe that's exactly what's happening.

Well, we can't back out the CVE fix, so I think just living with this
behavior (the SGID being cleared sometimes when it didn't need to be) is
our least bad option.  NFSv4 has the protocol we need to get this right,
and doesn't have this bug.

--b.

      reply	other threads:[~2018-05-15 22:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-25  6:03 SGID loss with nfsv3 Lu Xinyu
2018-04-30 20:16 ` J. Bruce Fields
2018-05-14  6:43   ` Lu Xinyu
2018-05-14 14:32     ` J. Bruce Fields
     [not found]       ` <5b6540f4-f744-5e51-c32f-c8809fbfed81@cn.fujitsu.com>
2018-05-15 20:41         ` J. Bruce Fields
2018-05-15 20:42           ` J. Bruce Fields
2018-05-15 21:47             ` Andreas Gruenbacher
2018-05-15 22:05               ` J. Bruce Fields [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180515220559.GD8178@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=agruenba@redhat.com \
    --cc=fnst-xmlinux@cn.fujitsu.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=luxy.fnst@cn.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).