Messages in this thread | | | Date | Sun, 08 Oct 2006 17:46:43 +0400 | From | Stas Sergeev <> | Subject | Re: [patch] honour MNT_NOEXEC for access() |
| |
Hello.
Arjan van de Ven wrote: > But when invoked manually.. there is even LESS special about it... it > could be ANY file on the system. And it's no different from any other > file in /bin, /usr/bin etc etc I agree with that completely, but it was not me who started adding the ld.so-specific tricks to the kernel, making it special. The assumptions of the current mmap check are: 1. The program does mmap with PROT_EXEC, not mmap/mprotect (it was explicitly pointed out that this is unlikely to change). 2. The program does the file-backed mmap, not the anon mmap then read. That suits ld.so very well because it happened to work that way, but it is not very usefull for pretty much anything else (unless someone can show the real-life examples). So this is what makes ld.so special. Right now it checks exec/noexec by trying mmap(PROT_EXEC) and see if that fails. But there can be other ways to check that, including the ones that will not break the other progs/configurations. And I don't see any harm in having a way for the program to explicitly say whether it wants an exec perm or not. (access() suits exactly for that, but it is racey)
>> Otherwise, please tell me, how can you solve the problem >> of ld.so started directly, can execute the files you do >> not have an exec permission for? > denying PROT_EXEC of non-"x" files does (somewhat). But you can't do that - lets be realistic. Also I wonder whether it will violate the posix specs or not.
> It's never fool > proof obviously, as long as you need to allow jits. Certainly.
>> Then ld.so can just use that to solve all those permission >> problems. > this is just entirely a wrong assumption; one based on the assumption > that ld.so is something special, that it isn't. Yes, that assumption is wrong, but it was not me who invented it. I only want to move the ld.so-specific stuff to ld.so itself, nothing more.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |