From e15e3202eb04048feb302b39d946f1ae1a15c306 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 26 Nov 2007 15:30:44 -0500 Subject: releasing version 2.14 --- doc/bugs/Symlinked_srcdir_requires_trailing_slash.mdwn | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) (limited to 'doc/bugs/Symlinked_srcdir_requires_trailing_slash.mdwn') diff --git a/doc/bugs/Symlinked_srcdir_requires_trailing_slash.mdwn b/doc/bugs/Symlinked_srcdir_requires_trailing_slash.mdwn index 0310c17f3..cd74c2496 100644 --- a/doc/bugs/Symlinked_srcdir_requires_trailing_slash.mdwn +++ b/doc/bugs/Symlinked_srcdir_requires_trailing_slash.mdwn @@ -63,4 +63,19 @@ My output: scanning index.mdwn rendering index.mdwn -Note that index.mdwn was only rendered when srcdir had a trailing slash. \ No newline at end of file +Note that index.mdwn was only rendered when srcdir had a trailing slash. + +> There are potential [[security]] issues with ikiwiki following a symlink, +> even if it's just a symlink at the top level of the srcdir. +> Consider ikiwiki.info's own setup, where the srcdir is ikiwiki/doc, +> checked out of revision control. A malicious committer could convert +> ikiwiki/doc into a symlink to /etc, then ikiwiki would happily publish +> all of /etc to the web. +> +> This kind of attack is why ikiwiki does not let File::Find follow +> symlinks when scanning the srcdir. By appending the slash, you're +> actually bypassing that check. Ikiwiki should not let you set +> up a potentially insecure configuration like that. More discussion of +> this hole [[here|security#index29h2]], and I've had to release +> a version of ikiwiki that explicitly checks for that, and fails to work. +> Sorry, but security trumps convenience. [[done]] --[[Joey]] -- cgit v1.2.3