linux-kernel - Re: [PATCH 02/24] rearrange may

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 19 Sep 2007 18:27:54 +0100
From:	Christoph Hellwig <hch@...radead.org>
To:	Dave Hansen <haveblue@...ibm.com>
Cc:	akpm@...l.org, linux-kernel@...r.kernel.org, hch@...radead.org
Subject: Re: [PATCH 02/24] rearrange may_open() to be r/o friendly

On Mon, Sep 17, 2007 at 11:27:20AM -0700, Dave Hansen wrote:
> 
> may_open() calls vfs_permission() before it does checks for
> IS_RDONLY(inode).  It checks _again_ inside of vfs_permission().
> 
> The check inside of vfs_permission() is going away eventually.
> With the mnt_want/drop_write() functions, all of the r/o
> checks (except for this one) are consistently done before
> calling permission().  Because of this, I'd like to use
> permission() to hold a debugging check to make sure that
> the mnt_want/drop_write() calls are actually being made.
> 
> So, to do this:
> 1. remove the IS_RDONLY() check from permission()
> 2. enforce that you must mnt_want_write() before
>    even calling permission()
> 3. enable a debugging in permission()
> 
> We need to rearrange may_open().  Here's the patch.

>  int permission(struct inode *inode, int mask, struct nameidata *nd)
>  {
>  	int retval, submask;
> +	struct vfsmount *mnt = NULL;
> +
> +	if (nd)
> +		mnt = nd->mnt;
>  
>  	if (mask & MAY_WRITE) {
>  		umode_t mode = inode->i_mode;
> @@ -251,7 +255,7 @@ int permission(struct inode *inode, int 
>  		 * MAY_EXEC on regular files is denied if the fs is mounted
>  		 * with the "noexec" flag.
>  		 */
> -		if (nd && nd->mnt && (nd->mnt->mnt_flags & MNT_NOEXEC))
> +		if (mnt && (mnt->mnt_flags & MNT_NOEXEC))

Why is this entirely unrelated cleanup in this patch?

Except for that it looks fine.
-
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/