Denied executable of mmap error

[ldunston]

I'm seeing this error in kern.log:

(default:D:/mnt/chrootusers/jailproto/opt/firefox/firefox-bin) denied executable mmap of /mnt/chrootusers/jails/5007/usr/share/mime/mime.cache by /mnt/chrootusers/jails/5007/opt/firefox/firefox-bin[firefox-bin:1040] uid/euid:5007/5007 gid/egid:5007/5007

The relavent policy has a rule to permit this:
subject /mnt/chrootusers/jailproto/opt/firefox/firefox-bin xoO {
....Omitting other lines
/mnt/chrootusers/jails/*/usr/share/mime/mime.cache x
}

I'm running grsecurity-2.9.1-3.6.7-201211251900.patch and obviously kernel 3.6.7.

I've straced firefox-bin and this is the relevant output:
stat64("/usr/share//mime/mime.cache", {st_mode=S_IFREG|0644, st_size=96788, ...}) = 0
open("/usr/share//mime/mime.cache", O_RDONLY|O_LARGEFILE) = 75
fstat64(75, {st_mode=S_IFREG|0644, st_size=96788, ...}) = 0
mmap2(NULL, 96788, PROT_READ, MAP_SHARED, 75, 0) = -1 EACCES (Permission denied)
close(75) = 0

It that error due to the difference in file paths (the extra / between share and mime from strace)? Or is there something else going on here to cause that error? From what I can tell the file flags are set correctly on mime.cache.

-rwxr-xr-x 1 root root 95K 2011-01-10 23:50 mime.cache

Here is the output from readelf -l firefox-bin:
Elf file type is EXEC (Executable file)
Entry point 0x8049d10
There are 9 program headers, starting at offset 52

Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x08048034 0x08048034 0x00120 0x00120 R E 0x4
INTERP 0x000154 0x08048154 0x08048154 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
LOAD 0x000000 0x08048000 0x08048000 0x0f7a8 0x0f7a8 R E 0x1000
LOAD 0x00fdfc 0x08058dfc 0x08058dfc 0x00320 0x0052c RW 0x1000
DYNAMIC 0x00fed4 0x08058ed4 0x08058ed4 0x00108 0x00108 RW 0x4
NOTE 0x000168 0x08048168 0x08048168 0x00044 0x00044 R 0x4
TLS 0x00fdfc 0x08058dfc 0x08058dfc 0x00000 0x00005 R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4
GNU_RELRO 0x00fdfc 0x08058dfc 0x08058dfc 0x00204 0x00204 R 0x1

Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .note.gnu.build-id .hash .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata .eh_frame
03 .ctors .dtors .jcr .data.rel.ro .dynamic .got .got.plt .data .bss
04 .dynamic
05 .note.ABI-tag .note.gnu.build-id
06 .tbss
07
08 .ctors .dtors .jcr .data.rel.ro .dynamic .got


Any help or suggestions are appreciated.

[ldunston]

Or perhaps it's this:

From mmap() manual:

The prot argument describes the desired memory protection of the mapping (and
must not conflict with the open mode of the file). It is either PROT_NONE or
the bitwise OR of one or more of the following flags:


PROT_EXEC Pages may be executed.

PROT_READ Pages may be read.

PROT_WRITE Pages may be written.

PROT_NONE Pages may not be accessed.

Wonder if this part of read_implies_exec issue discussed in this thread: viewtopic.php?f=3&t=1890

I've tried adding the additional read flag to mime.cache but it doesn't seem to change the behavior.