Re: [PATCH] vfs: fix IMA lockdep circular locking dependency

[Al Viro <viro@ZenIV.linux.org.uk>]

On Wed, May 30, 2012 at 03:42:47PM -0400, Eric Paris wrote:
> security_file_mmap() would pretty much only be used in do_mmap_pgoff()
> (or validate_mmap_request)

Callers, actually - the whole point is to lift it out of under ->mmap_sem.
The tricky part is reqprot vs. prot mess.

In all cases, we need current to be READ_IMPLIES_EXEC and prot to contain
PROT_READ for any changes to happen.  Assuming that both conditions are
met, we have the following:
file == NULL:
	add PROT_EXEC in !MMU case, don't do that for MMU.
file != NULL, lives on fs mounted noexec: don't modify prot
file != NULL, lives on fs mounted without noexec:
	MMU - add PROT_EXEC; !MMU - add it only if we have BDI_CAP_EXEC_MAP on
that file.

AFAICS, the least painful way of dealing with that would be to have
something like
mangle_prot(struct file *file, unsigned long *prot, unsigned long flags)

that would handle that logics and call security_file_mmap().  With separate
instances in MMU and !MMU cases ;-/  However, there's an extra fun in there -
consider fs/aio.c caller of do_mmap().  For MMU case we don't really care.
But what about !MMU?  Should that guy get PROT_EXEC slapped on it?