From mboxrd@z Thu Jan 1 00:00:00 1970 From: i at monkz.de (MonkZ) Date: Mon, 13 Mar 2017 09:59:32 +0100 Subject: cgit and symlinks In-Reply-To: <20170312141847.GI2102@john.keeping.me.uk> References: <08c0a64a-7df9-9b24-f40e-87eea9d53f77@schinagl.nl> <20170306233525.GD2102@john.keeping.me.uk> <5435925d-c258-4196-ce9b-d08348593624@monkz.de> <20170308123021.GE2102@john.keeping.me.uk> <1f050421-f221-a8b2-75f0-43f04fd3bfd9@monkz.de> <20170309001535.GG2102@john.keeping.me.uk> <332ab30e-0e22-e702-7561-664e1ed32a87@monkz.de> <20170312141847.GI2102@john.keeping.me.uk> Message-ID: <8cfc8876-bff3-33eb-2e1e-03971f9cc195@monkz.de> Am 12.03.2017 um 15:18 schrieb John Keeping: > On Thu, Mar 09, 2017 at 08:58:43AM +0100, MonkZ wrote: >> Am 09.03.2017 um 01:15 schrieb John Keeping: >>> 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? >>> >> >> Absolute symlinks must be ignored. There is no deterministic way to >> resolve them - every clone can be at a different location, and there >> isn't really a deterministic mapping from url to filesystem. Absolute >> symlinks would only work if resolved internally - with additional >> security risks. >> >> Relative inter-repository links may allowed/handled/redirected if >> explicitly configured, otherwise it might be confusing if the server >> layout doesn't match. On the other hand a notification "This is a >> symlink outside this repository" might suffice (but i don't have a plan >> for plain-ui). > > We can consider improvements to the tree UI separately, but I really > don't think we should be getting into anything clever with symlinks in > the plain UI because it ends up with complicated rules like the above. > > It's difficult to explain and will end up surprising users, so my > preference is for my original patch that just displays the content of > the blob when a symlink is found. This is consistent with both > "git show" and "git cat-file". Yep, it's a tough decision to make - full support of symlinks(in my eyes can't be done to serve all usecases), only relative symlinks or none. One argument for "only relative symlinks": Olliver Schinagl had his git to debian-repository usecase, that would still be possible if he copies the files in place of the symlink - git compression would take care of deduplication. On the other hand checking out said repository/branch could lead to a full filesystem. Config option would be s.th. like "handle_relative_symlinks" or offering a "symlink filter" hook for users to write own scripts. One argument for "none": "do one thing and do it well" and if we can't handle absolute symlinks, we should leave them alone. MfG MonkZ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: