summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJoey Hess <joey@gnu.kitenet.net>2010-04-06 13:58:55 -0400
committerJoey Hess <joey@gnu.kitenet.net>2010-04-06 13:58:55 -0400
commitc87ddb6908485fecff9c516223ca0b2973df88f6 (patch)
tree5b85b1507549d1bfef3005ab9572331f7b6d3d7f
parent089a7faff8defe98ffc593702be93f8f35d2153a (diff)
idea
-rw-r--r--doc/todo/optional_underlaydir_prefix.mdwn24
1 files changed, 24 insertions, 0 deletions
diff --git a/doc/todo/optional_underlaydir_prefix.mdwn b/doc/todo/optional_underlaydir_prefix.mdwn
index 8fd6d76c5..dd11d062d 100644
--- a/doc/todo/optional_underlaydir_prefix.mdwn
+++ b/doc/todo/optional_underlaydir_prefix.mdwn
@@ -4,6 +4,9 @@ Use-case 1 (to keep things tidy):
Currently IkiWiki has some javascript files in `underlays/javascript`; that directory is given as one of the underlay directories. Thus, all the javascript files appear in the root of the generated site. But it would be tidier if one could say "put the contents of *this* underlaydir under the `js` directory".
+> Of course, this could be accomplished, if we wanted to, by moving the
+> files to `underlays/javascript/js`. --[[Joey]]
+
Use-case 2 (a read-only external dir):
Suppose I want to include a subset of `/usr/local/share/docs` on my wiki, say the docs about `foo`. But I want them to be under the `docs/foo` sub-directory on the generated site. Currently I can't do that. If I give `/usr/local/share/docs/foo` as an underlaydir, then the contents of that will be in the root of the site, rather than under `docs/foo`. And if I give `/usr/local/share/docs` as an underlaydir, then the contents of the `foo` dir will be under `foo`, but it will also include every other thing in `/usr/local/share/docs`.
@@ -17,4 +20,25 @@ I'm not sure how this would be implemented, but I guess it could be configured s
'docs/foo' => '/usr/local/share/docs/foo',
}
+> So, let me review why symlinks are an issue. For normal, non-underlay
+> pages, users who do not have filesystem access to the server may have
+> commit access, and so could commit eg, a symlink to `/etc/passwd` (or
+> to `/` !). The guards are there to prevent ikiwiki either exposing the
+> symlink target's contents, or potentially overwriting it.
+>
+> Is this a concern for underlays? Most of the time, certianly not;
+> the underlay tends to be something only the site admin controls.
+> Not all the security checks that are done on the srcdir are done
+> on the underlays, either. Most checks done on files in the underlay
+> are only done because the same code handles srcdir files. The one
+> exception is the test that skips processing symlinks in the underlay dir.
+> (But note that the underlay directory can be a symlinkt to elsewhere
+> which the srcdir, by default, cannot.)
+>
+> So, one way to approach this is to make ikiwiki follow directory symlinks
+> inside the underlay directory. Just a matter of passing `follow => 1` to
+> find. (This would still not allow individual files to be symlinks, because
+> `readfile` does not allow reading symlinks. But I don't see much need
+> for that.) --[[Joey]]
+
[[!taglink wishlist]]