Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752387AbcLFOpe (ORCPT ); Tue, 6 Dec 2016 09:45:34 -0500 Received: from mail-qt0-f174.google.com ([209.85.216.174]:33816 "EHLO mail-qt0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751675AbcLFOpb (ORCPT ); Tue, 6 Dec 2016 09:45:31 -0500 Message-ID: <1481035527.2573.14.camel@redhat.com> Subject: Re: FUSE: regression when clearing setuid bits on chown From: Jeff Layton To: Miklos Szeredi Cc: linux-fsdevel , open list , Al Viro Date: Tue, 06 Dec 2016 09:45:27 -0500 In-Reply-To: <20161206143914.GG2622@veci.piliscsaba.szeredi.hu> References: <1480962075.2544.30.camel@redhat.com> <20161206100243.GF2622@veci.piliscsaba.szeredi.hu> <1481026405.2573.10.camel@redhat.com> <20161206143914.GG2622@veci.piliscsaba.szeredi.hu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3810 Lines: 110 On Tue, 2016-12-06 at 15:39 +0100, Miklos Szeredi wrote: > On Tue, Dec 06, 2016 at 07:13:25AM -0500, Jeff Layton wrote: > > > > > Should we be checking that the latest i_mode even has these bits before > > sending down the mode change? > > Fixed, see updated patch below. > > It also fixes a bug in the previous patch where in case of "-rwsrwSr-x" it would > clear the sgid bit without execute. > > > > > > > > > > > > > > > > + attr->ia_mode = inode->i_mode & ~(S_ISUID | S_ISGID); > > > + attr->ia_valid |= ATTR_MODE; > > > } > > > } > > > if (!attr->ia_valid) > > > > Yeah that is quite a bit simpler. > > > > That said...if either ATTR_KILL flag is set, then we're going to end up > > clearing both bits in the new mode. I guess that's ok since we always > > want to clear them both, and we'll only have one set and not the other > > if one of the mode bits was set and not the other. > > > > But...I'm starting to wonder if we really need two flags for this. Would > > be be better served with a single ATTR_KILL_SUID_SGID flag? I wonder if > > that would simplify some of the logic in the whole setuid clearing > > morass. > > Yeah, that would be a nice little cleanup. > > Thanks, > Miklos > --- > > From: Miklos Szeredi > Subject: fuse: fix clearing suid, sgid for chown() > > Basically, the pjdfstests set the ownership of a file to 06555, and then > chowns it (as root) to a new uid/gid. Prior to commit a09f99eddef4 ("fuse: > fix killing s[ug]id in setattr"), fuse would send down a setattr with both > the uid/gid change and a new mode. Now, it just sends down the uid/gid > change. > > Technically this is NOTABUG, since POSIX doesn't _require_ that we clear > these bits for a privileged process, but Linux (wisely) has done that and I > think we don't want to change that behavior here. > > This is caused by the use of should_remove_suid(), which will always return > 0 when the process has CAP_FSETID. > > In fact we really don't need to be calling should_remove_suid() at all, > since we've already been indicated that we should remove the suid, we just > don't want to use a (very) stale mode for that. > > This patch should fix the above as well as simplify the logic. > > Reported-by: Jeff Layton > Signed-off-by: Miklos Szeredi > Fixes: a09f99eddef4 ("fuse: fix killing s[ug]id in setattr") > Cc: > --- > fs/fuse/dir.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > --- a/fs/fuse/dir.c > +++ b/fs/fuse/dir.c > @@ -1739,8 +1739,6 @@ static int fuse_setattr(struct dentry *e > * This should be done on write(), truncate() and chown(). > */ > if (!fc->handle_killpriv) { One more thing too. I don't think we really want to monkey with the mode at all if there is a request to set the mode already in the request. So maybe this should be:     if (!fc->handle_killpriv && !(attr->ia_mode & ATTR_MODE)) Granted that won't generally happen from normal process context, but we could have knfsd in here too and I think that's possible from there. > - int kill; > - > /* > * ia_mode calculation may have used stale i_mode. > * Refresh and recalculate. > @@ -1750,12 +1748,11 @@ static int fuse_setattr(struct dentry *e > return ret; > > attr->ia_mode = inode->i_mode; > - kill = should_remove_suid(entry); > - if (kill & ATTR_KILL_SUID) { > + if (inode->i_mode & S_ISUID) { > attr->ia_valid |= ATTR_MODE; > attr->ia_mode &= ~S_ISUID; > } > - if (kill & ATTR_KILL_SGID) { > + if ((inode->i_mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) { > attr->ia_valid |= ATTR_MODE; > attr->ia_mode &= ~S_ISGID; > } Looks good otherwise! -- Jeff Layton