Date: Mon, 13 Feb 2017 10:28:21 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 217062] ZFS exec=off property does not work for mmap Message-ID: <bug-217062-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217062 Bug ID: 217062 Summary: ZFS exec=3Doff property does not work for mmap Product: Base System Version: 11.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: shamaz.mazum@gmail.com Created attachment 179941 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D179941&action= =3Dedit Test for the bug Hello. I've noticed that you can execute a code from ZFS filesystem with ex= ec property set to off with mmap'ing it with PROT_READ | PROT_EXEC protection.= If this is not done at mmap time, further calls to mprotect trying to set PROT_EXEC protection will fail. For example, I cannot launch SBCL with core image in my no-exec home direct= ory (because it calls mprotect), but I can execute any code from shared librari= es in home directory if I open it with dlopen(). It seems to me as a bug, so I report. I attach a working example to illustrate a problem. It will require some tuning. In the attached archive compile lib.c as a shared library. Then pla= ce it in no-exec ZFS filesystem. Then compile test-working.c and test-bug.c, replacing hard-coded values in calls to open() and mmap() (filename and add= ress of return_value. You can get the address with objdump -T). Place binaries somewhere you can execute them. Execute test-working at first. It will fail= to work if library is in no-exec FS. Then execute test-bug. It will return the value 4 from the library no matter where it is stored. Even if it is on no-= exec FS, it will be executed. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-217062-8>