response to response
[ikiwiki.git] / doc / forum / Apache_XBitHack.mdwn
1 I'd like to be able to use the Apache XBitHack to enable Server Side Includes on my site.  Yes, it is possible to enable SSI by setting the page extension to .shtml, and that is what I am doing at the moment.
2 However, the disadvantage of this approach is that the server does not give a LastModified header, which means that the content can't be cached.  However, the way that I am using SSI is such that the main content of the page really is "last modified" when the page was last modified, so I'd like to be able to indicate that.  And using the XBitHack - that is, setting the executable bit on the generated page - would enable me to do that.
3
4 I gather from the [[security]] page that having the executable bit set on files is considered a security hole, but how big a hole would it be if I'm the only one editing the site?  Is there a way, a somewhat safe way, of implementing XBitHack for IkiWiki?
5
6 -- [[KathrynAndersen]]
7
8 > The risk with execute bits on files in the generated site is that someone
9 > commits an executable, ikiwiki copies it as-is, and now the web browser
10 > can be used to run it. Obviously if you're the only committer, that is 
11 > not much of a risk. Or you can lock down apache to not allow running
12 > arbitrary files. It's also pretty unlikely that a rendered mdwn file
13 > would result in a html page that can be run as an executable. So an
14 > option that makes all files rendered from mdwn or other markups 
15 > get the x bit set would be pretty safe even with untrusted editors. --[[Joey]] 
16
17 >> So how about this: if something has a page-type (i.e. mdwn or whatever authorized page types there are)
18 >> then add something at the end of the process (would that be the "changes" hook?)
19 >> which sets the x bit on the generated page file.  Would that work?
20 >> --[[KathrynAndersen]]