Changes between Version 1 and Version 2 of Ticket #60

Nov 23, 2009, 3:41:41 AM (12 years ago)

binfmt_misc is gone (#105) (except for Mono, for which we now use a magic number instead of an extension). So the only issues left are that we could be doing better for PHP and static content.

Quentin wants to do something involving reusing the Apache code for static content. This could be awesome if the implementation can be made sane and secure.


  • Ticket #60

    • Property Summary changed from Replace binfmt_misc with Apache handlers to Apache handlers for PHP and static content
  • Ticket #60 – Description

    v1 v2  
    1 Our AFS patch currently marks every file as executable.  This was done to allow the binfmt_misc hack to work for Perl, PHP, Python, and Mono scripts.  Previously binfmt_misc was also used for static content, until it became clear that this opens an exploitable security problem with MediaWiki uploads.
    3 We should be able to completely replace the binfmt_misc hack with a solution based on Apache handlers.
    4  * I suspect Perl and Python don’t need special handlers at all (since Perl and Python programmers expect to need shebang lines), although we may need some kind of transition period to check whether users are relying on the executable bit.
     1We currently launch PHP and static-cat directly from suexec.  We should be able to replace this hack with a solution based on Apache handlers.
    52 * We can wrap PHP in a handler that performs extra security checks, such as that the extension really is .php.  This handler could later grow into the FastCGI PHP proxy pony.  It could also solve #2.
    63 * Static content should also become a handler, so that users can add their own static extensions.
    7  * As for Mono, well, what the fuck.  (Maybe keep binfmt_misc but require explicit executable bits for that.)
    95The hardest problem is how to get these Apache handlers to run with the correct uid.  My last proposal was a FUSE filesystem that I have prototyped at /mit/andersk/Public/scripts/scriptswrapfs.c, but I’d be interested in better ideas.