[<prev] [next>] [day] [month] [year] [list]
Message-Id: <200708301506.l7UF6Sad002128@dantu.rdu.redhat.com>
Date: Thu, 30 Aug 2007 11:06:28 -0400
From: Jeff Layton <jlayton@...hat.com>
To: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Cc: linux-cifs-client@...ts.samba.org, nfs@...ts.sourceforge.net
Subject: [PATCH 0/3] fix setuid/setgid clearing in networked filesystems (take 4)
When an unprivileged process attempts to modify a file that has the
setuid or setgid bits set, the VFS will attempt to clear these bits. The
VFS will set the ATTR_KILL_SUID or ATTR_KILL_SGID bits in the ia_valid
mask, and then call notify_change to clear these bits and set the mode
accordingly.
With a networked filesystem (NFS and CIFS in particular but likely
others), the client machine or process may not have credentials that
allow for setting the mode. In some situations, this can lead to file
corruption, an operation failing outright because the setattr fails, or
to races that lead to a mode change being reverted.
In this situation, we'd like to just leave the handling of this to the
server and ignore these bits. The problem is that by the time the
setattr op is called, the VFS has already reinterpreted the ATTR_KILL_*
bits into a mode change and the setattr operation has no way to
know its intent.
The following patchset fixes this by making notify_change no longer
clear the ATTR_KILL_SUID and ATTR_KILL_SGID bits in the ia_valid before
handing it off to the setattr inode op. setattr can then check for the
presence of these bits, and if they're set it can assume that the mode
change was only for the purposes of clearing these bits.
This means that we now have an implicit assumption that notify_change is
never called with ATTR_MODE and either ATTR_KILL_S*ID bit set. Nothing
currently enforces that, so the patch also adds a BUG_ON() if that
occurs.
The other two patches in the set fix up NFS and CIFS to ignore
the mode change if either ATTR_KILL_S*ID bit is set.
Signed-off-by: Jeff Layton <jlayton@...hat.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists