linux-kernel - FUSE: regression when clearing setuid bits on chown

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 05 Dec 2016 13:21:15 -0500
From:   Jeff Layton <jlayton@...hat.com>
To:     Miklos Szeredi <miklos@...redi.hu>
Cc:     linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>
Subject: FUSE: regression when clearing setuid bits on chown

Hi Miklos,

I think we've found a "regression" that has crept in due to this patch:

commit a09f99eddef44035ec764075a37bace8181bec38
Author: Miklos Szeredi <mszeredi@...hat.com>
Date:   Sat Oct 1 07:32:32 2016 +0200

    fuse: fix killing s[ug]id in setattr

Basically, the pjdfstests set the ownership of a file to 06555, and then
chowns it (as root) to a new uid/gid. Prior to the patch above, 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.

So, the issue I think is the use of should_remove_suid, which will
always return 0 when the process has CAP_FSETID. That's appropriate (I
think) for write/truncate, but not chown, where we want to ignore that.

Thoughts on the right fix here? A simple fix would be to add an
"override" bool to should_remove_suid, but maybe there's some more
elegant way to do it?

-- 
Jeff Layton <jlayton@...hat.com>