From: john at keeping.me.uk (John Keeping)
Subject: cgit and symlinks
Date: Thu, 9 Mar 2017 00:15:35 +0000 [thread overview]
Message-ID: <20170309001535.GG2102@john.keeping.me.uk> (raw)
In-Reply-To: <1f050421-f221-a8b2-75f0-43f04fd3bfd9@monkz.de>
On Wed, Mar 08, 2017 at 02:28:11PM +0100, MonkZ wrote:
>
>
> Am 08.03.2017 um 13:30 schrieb John Keeping:
> > On Wed, Mar 08, 2017 at 12:38:38PM +0100, MonkZ wrote:
> >> Am 07.03.2017 um 00:35 schrieb John Keeping:
> >>> We can't reliably follow the link because there is no guarantee that the
> >>> target lies within the repository and I don't know what we would output
> >>> for the case where we can't display the target.
> >>
> >> INADH (I'm not a dev here)
> >>
> >> I would recommend to continue ignoring it or returning the blob, because
> >> following symlinks (internally) might result - if not done carefully -
> >> in directory traversal security issues. Maybe resolving a symlink to a
> >> HTTP301 could work.
> >>
> >> For the UI there might be a html-link (in a notification box "This is a
> >> symlink that points to ...") to the symlink-destination below or above
> >> the blob, to get a user via click to a file/directory.
> >
> > We're talking about the "plain" UI here (for example [0]), so we don't
> > have anywhere to put additional content and it has to be something
> > basic.
> Of course. It would be handled like a content-rewrite to return a http301.
>
> Pseudocode:
> handle_symlinks = True # new config item
> if this_file_is_a_symlink and symlink_is_relative and handle_symlinks:
> if plain_ui:
> # rewrite blob to http301
> # by attaching the path to the end of current basedir
> # cgit is already able to handle ../ in a path
> if !plain_ui:
> # show blob
> # show notification that this is a symlink
> # show a link to a url
> # like the one that would be used in plain_ui
>
> >
> > I'm not actually too worried about directory traversal if we were to try
> > following links because we're looking things up in a Git tree at a
> > particular commit and not on the filesystem. A bigger concern would be
> > whether the internals of Git do anything bad (like invalid memory
> > access) if we give the tree traversal machinery a path that goes up out
> > of the repository; I doubt it but I have not checked.
> If we use url-rewrites (and let the http-client care about getting the
> correct file or directory), this would be a non-issue.
It could also mean that cross-repository symlinks work if the server
layout matches that that is expected for checkouts of the repositories.
But it's not exactly helpful if a repository contains an absolute
symlink and I don't think we want to start figuring out whether a
redirect makes sense - what do we do if we decide it doesn't?
next prev parent reply other threads:[~2017-03-09 0:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-06 10:42 oliver+cgit
2017-03-06 23:35 ` john
2017-03-08 11:38 ` i
2017-03-08 12:30 ` john
2017-03-08 13:28 ` i
2017-03-09 0:15 ` john [this message]
2017-03-09 7:58 ` i
2017-03-12 14:18 ` john
2017-03-13 8:59 ` i
2017-03-21 4:56 ` dlcampbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170309001535.GG2102@john.keeping.me.uk \
--to=cgit@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).