pointing out the existence of field

[ikiwiki] / doc / todo / optional_underlaydir_prefix.mdwn

For security reasons, symlinks are disabled in IkiWiki.  That's fair enough, but that means that some problems, which one could otherwise solve by using a symlink, cannot be solved. The specfic problem in this case is that all underlays are placed at the root of the wiki, when it could be more convenient to place some underlays in specific sub-directories.

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`.

Since we can't use symlinks in an underlay dir to link to these directories, then perhaps one could give a specific underlay dir a specific prefix, which defines the sub-directory that the underlay should appear in.

I'm not sure how this would be implemented, but I guess it could be configured something like this:

    prefixed_underlay => {
         'js' => '/usr/local/share/ikiwiki/javascript',
         '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]]

>> If you think that enabling symlinks in underlay directories wouldn't be a security issue, then I'm all for it!  That would be much simpler to implement, I'm sure. --[[KathrynAndersen]]

[[!taglink wishlist]]