On Thu, Jun 05, 2014 at 06:40:36AM +0200, Michael Kerrisk (man-pages) wrote:
> On 06/05/2014 01:31 AM, Dave Jones wrote:
> > I just noticed that trinity was freaking out in places when mmap was
> > returning zero. This surprised me, because I had the mmap_min_addr
> > sysctl set to 64k, so it wasn't a MAP_FIXED mapping that did it.
> >
> > There's no mention of this return value in the man page, so I dug
> > into the kernel code, and it appears that we do..
> >
> > sys_mmap
> > vm_mmap_pgoff
> > security_mmap_file
> > ima_file_mmap <- returns 0 if not PROT_EXEC
> >
> > and then the 0 gets propagated up as a retval all the way to userspace.
> >
> > It smells to me like we might be violating a standard or two here, and
> > instead of 0 ima should be returning -Esomething
> >
> > thoughts?
>
> Seems like either EACCESS or ENOTSUP is appropriate; here's the pieces
> from POSIX:
>
> EACCES The fildes argument is not open for read, regardless of
> the protection specified, or fildes is not open for
> write and PROT_WRITE was specified for a MAP_SHARED type
> mapping.
>
> ENOTSUP
> The implementation does not support the combination
> of accesses requested in the prot argument.
>
> ENOTSUP seems to be more appropriate in my reading of the above, though
> I'd somehow more have expected EACCES.
I just realised that this affects even kernels with CONFIG_IMA unset,
because there we just do 'return 0' unconditionally.
Also, it appears that kernels with CONFIG_SECURITY unset will also
return a zero for the same reason.
This is kind of a mess, and has been that way for a long time.
Fixing this will require user-visible breakage, but in this case
I think it's justified as there's no way an app can do the right thing
if it gets a 0 back. Linus ?
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
