[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110531180643.GB9261@alboin.amr.corp.intel.com>
Date: Tue, 31 May 2011 11:06:43 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Steven Whitehouse <swhiteho@...hat.com>
Cc: Andi Kleen <andi@...stfloor.org>, viro@...iv.linux.org.uk,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
chris.mason@...cle.com, josef@...hat.com, agruen@...bit.com,
"Serge E. Hallyn" <serue@...ibm.com>
Subject: Re: [PATCH 1/4] Cache xattr security drop check for write v2
> It sounds like a good idea, but cluster filesystems will need to clear
> the flag when they update their in-core inodes. Without that we could
> have:
>
> Node A looks up inode and sets S_NOSEC since its not suid
> Node B does chmod +s on the inode
> Node A now has S_NOSEC set, but inode is suid, so writes don't clear
> suid
Good point. I assume that's also true for network file systems.
This would essentially argue that for those putting the helper
into the inode read paths is not optional. I'll look into this
later.
> - flags &= ~(S_SYNC|S_APPEND|S_IMMUTABLE|S_NOATIME|S_DIRSYNC);
> + flags &= ~(S_SYNC|S_APPEND|S_IMMUTABLE|S_NOATIME|S_DIRSYNC|S_NOSEC);
> + if (!is_sxid(inode->i_mode))
> + flags |= S_NOSEC;
Doesn't that need a check for no xattr too? or do you not support
those currently?
Note I added a helper for this in the latest version:
inode_has_no_xattr()
-Andi
--
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