[Top] [All Lists]

Re: [PATCH 0/5 v2 RESEND] fs: Fixes for removing xid bits and security l

To: Jan Kara <jack@xxxxxxx>
Subject: Re: [PATCH 0/5 v2 RESEND] fs: Fixes for removing xid bits and security labels
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 5 May 2015 09:13:10 +1000
Cc: Al Viro <viro@xxxxxxxxxxxxxxxxxx>, linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <1425379119-3773-1-git-send-email-jack@xxxxxxx>
References: <1425379119-3773-1-git-send-email-jack@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, Mar 03, 2015 at 11:38:34AM +0100, Jan Kara wrote:
>   Hello,
>   warning in XFS made me look into detail into how clearing of suid / sgid
> bits and security labels is done. And I've spotted a few issues:
> 1) MS_NOSEC handling is broken - we set it after each file_remove_suid() call.
>    However we needn't have removed suid bit simply because we have
>    CAP_SYS_FSID and further writes to the file from processes without this
>    capability still need to clear the suid bit.
> 2) file_remove_suid() is a misnomer since it also handles removing of
>    security labels. It is even more confusing because should_remove_suid()
>    doesn't return whether file_remove_suid() is needed or not.
> 3) On truncate we do clear suid bits but not security labels. According to
>    documentation in include/linux/security.h that's a bug but please correct
>    me if I'm wrong.
> 4) ocfs2 doesn't clear security labels - hard to fix, I left it alone for now.
> 5) XFS didn't provide proper exclusion for clearing mode bits.
>   This series aims at fixing above issues.
>   Since v1 I have removed bogus patch changing inode_set_flags(), I have
> updated changelog of patch 4/5 to better explain why ->inode_killpriv should
> be called and I have included a fix for MS_NOSEC handling in this series.
> Al, can you please merge the patches? Thanks!

Hi Al + Jan,

What's happening with this patchset? If it's not going to be pulled
into the VFS, I'll just pull in a version of the XFS patch that
corrects the locking at this point...


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>