Changes between Initial Version and Version 1 of Ticket #60


Ignore:
Timestamp:
Jan 3, 2009, 4:03:17 AM (15 years ago)
Author:
quentin
Comment:

We no longer automatically set +x on files. We still support binfmt_misc. I am downgrading the severity of this bug.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #60

    • Property Priority changed from major to minor
    • Property Type changed from defect to enhancement
    • Property Summary changed from Replace executable bit and binfmt_misc with Apache handlers to Replace binfmt_misc with Apache handlers

  • Ticket #60 – Description

    initial v1  
    11Our 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.
    22
    3 I believe the executable bit is still be a security danger (albeit not as immediately exploitable) because fundamentally, it defeats a suexec sanity check.  It should be harder for an attacker to put an executable file inside web_scripts than a normal file, so that an Apache compromise does not spread to other accounts via suexec.
    4 
    5 We should be able to completely replace the executable bit+binfmt_misc hack with a solution based on Apache handlers.
     3We should be able to completely replace the binfmt_misc hack with a solution based on Apache handlers.
    64 * 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.
    75 * 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.