Traversing symlinks

Dominik Psenner dpsenner at gmail.com
Thu May 19 08:00:28 CDT 2011


> -----Original Message-----
> From: Matt Mackall [mailto:mpm at selenic.com]
> Sent: Tuesday, May 17, 2011 8:52 PM
> To: Dominik Psenner
> Cc: 'Martin Geisler'; 'Mercurial Developers'
> Subject: RE: Traversing symlinks
> 
> On Tue, 2011-05-17 at 14:02 +0200, Dominik Psenner wrote:
> > > -----Original Message-----
> > > From: mercurial-devel-bounces at selenic.com [mailto:mercurial-devel-
> > > bounces at selenic.com] On Behalf Of Matt Mackall
> > > Sent: Monday, May 16, 2011 8:14 PM
> > > To: Martin Geisler
> > > Cc: Mercurial Developers
> > > Subject: Re: Traversing symlinks
> > >
> > > On Mon, 2011-05-16 at 19:57 +0200, Martin Geisler wrote:
> > > > Hi guys,
> > > >
> > > > Way back in 2007, this changeset was added:
> > > >
> > > >   http://selenic.com/hg/rev/d316124ebbea
> > > >
> > > > It makes Mercurial abort when it encounters a symlink on the way to
> a
> > > > file -- even when the symlink points inside the repository:
> > > >
> > > >   $ ln -s contrib extra
> > > >   $ hg status extra/mq.el
> > > >   abort: path 'extra/mq.el' traverses symbolic link 'extra'
> > > >
> > > > This seems a tad too restrictive to me,
> > >
> > > Ok, do tell, what have you lost by not being able to ask for the
> status
> > > of a path you can't commit?
> > >
> > > >  and Bryan did also flag this in
> > > > the test and commit message.
> > > >
> > > > Would anybody object to me lifting this restriction?
> > >
> > > Yes.
> > >
> > > Most developers have only the vaguest idea of what the security
> > > implications of symlinks are, and simply saying "this seems a tad too
> > > restrictive" does not instill confidence that you've spent the time to
> > > become an expert on this obscure and complicated subject.
> >
> > Isn't this something that is left over to whoever administrates a
> > repository? Surely there are many cases and side-effects that may cause
> > problems, but is it really hg's role to decide if it's fine or not?
> 
> Yes, it's definitely Mercurial's role to prevent you from getting 0wned
> when you clone a random project from Bitbucket without even running it.

I can agree in one point: Mercurial should prevent you from evil things.
This means that when it comes down to writing something into the filesystem
mercurial should of course be very restrictive.

But when it comes down to reading from a repository, mercurial can safely
follow symlinks. The point there is, that mercurial did not create the
symlink. So it must have been someone else who manually placed things. That
user must have had write access to that directory and thus was either the
guy himself or a superuser. If it was not one of them, the system has been
hijacked and can't be trusted anyway. At this point arbitrary commands could
be mined with evil things.



More information about the Mercurial-devel mailing list