From patchwork Tue Dec 6 14:39:14 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Miklos Szeredi X-Patchwork-Id: 9462719 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id DA97D60236 for ; Tue, 6 Dec 2016 14:40:07 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CC9352840C for ; Tue, 6 Dec 2016 14:40:07 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C108D2841C; Tue, 6 Dec 2016 14:40:07 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0FDC32840C for ; Tue, 6 Dec 2016 14:40:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752151AbcLFOkF (ORCPT ); Tue, 6 Dec 2016 09:40:05 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:36382 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751058AbcLFOkE (ORCPT ); Tue, 6 Dec 2016 09:40:04 -0500 Received: by mail-wm0-f68.google.com with SMTP id m203so21863832wma.3 for ; Tue, 06 Dec 2016 06:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=z9u6N+6CzhPjDJbFJ12PtxRxc6BvTHzL3uNTi+AHTOk=; b=bu8XGfLOSVAqNjQ7sZFxx8GVoUkOij8tA8nQj3CB059bJ5JxtPtAyZCdNqp7zev2cO h87CyFOGkZdxHPkTYWWB9cBCkShWs8JkPue7Ny035wqWSCEPVk2QaRQLCutzu5NQd3bx kvn1ejt/WjlS+ln7FIR5QeTa7zwT6bF39YStk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=z9u6N+6CzhPjDJbFJ12PtxRxc6BvTHzL3uNTi+AHTOk=; b=Rc60LBUL2vEaHWQQhcwkjAGHR7u9XpDdiFf/aoHrlDJoTZ/qNxWFQxxKzUFJY0MwJ4 7l7SvMqlApYuMMSg87yEOvUsX2W9R5XIsTOKOIqeGmD5KCziuXWTBpZuFmOQqzwz+WTq ZqKmf0sucAcnrn0KSy8iosxgNKrMXbb1vV1fMPR105DQbWWg2ow00Npt6dQiyMTks7Cl gIxls1FW2gRxSJmGQyPN15TW/VGYmDoZqQVabSUqCVsN/0ce2OxCHiPmKD5WxqBptRz7 pZT+ozdvVCAmS2WYLRGK27L+vcRyO9mCfR8HldLX3n7CK8uESYfkHXJwh31zyYwTlVUM GixQ== X-Gm-Message-State: AKaTC01RVeXPUISZg2sXp33vHyP975d5b3RjIDgZqk7Nv4dF77tPzMx2OfC+QlcHP1qLfA== X-Received: by 10.28.111.139 with SMTP id c11mr3237295wmi.139.1481035157810; Tue, 06 Dec 2016 06:39:17 -0800 (PST) Received: from veci.piliscsaba.szeredi.hu (pool-dsl-2c-0018.externet.hu. [217.173.44.24]) by smtp.gmail.com with ESMTPSA id r138sm4356055wme.9.2016.12.06.06.39.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Dec 2016 06:39:16 -0800 (PST) Date: Tue, 6 Dec 2016 15:39:14 +0100 From: Miklos Szeredi To: Jeff Layton Cc: linux-fsdevel , open list , Al Viro Subject: Re: FUSE: regression when clearing setuid bits on chown Message-ID: <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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1481026405.2573.10.camel@redhat.com> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 Reviewed-by: Jeff Layton --- 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(-) -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- 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) { - 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; }