linux-kernel - Re: [patch 07/14] vfs: pass dentry to permission()

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]

Message-ID: <20080521202914.GP28946@ZenIV.linux.org.uk>
Date:	Wed, 21 May 2008 21:29:14 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	linux-fsdevel@...r.kernel.org, hch@...radead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 07/14] vfs: pass dentry to permission()

On Wed, May 21, 2008 at 07:15:05PM +0200, Miklos Szeredi wrote:
> From: Miklos Szeredi <mszeredi@...e.cz>
> 
> The following patches clean up the i_op->permission() method and the
> related VFS API.
> 
> Here's an overview of the changes:
> 
>  - ->permission() is passed a dentry instead of an inode
>  - ->permission() is passed a integer flags parameter instead of a
>    nameidata pointer

No.  Take a good look at the instances.

	a) only one aberrant case cares about dentry, and for extremely
wrong reasons.  /proc/sys/ stuff.  ecryptfs, of course, will be happy
with any variant.
	b) few flags that are looked at are trivially mapped to new MAY_...

I have a patch series that does it, but it involves tons of fixing the
sysctl handling to be finished ;-/  And yes, we need sysctl to quit
doing the "I want to get ctl_table entry, so I'll do very painful search
by dentry every damn time" in any case - look at that code, it's far
too ugly to live.

IOW, consider this ->permission() API change NAKed.
--
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/