You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Chris Pickett <ch...@mail.mcgill.ca> on 2005/02/22 23:44:52 UTC
svn URL's with '..' elements
Hi,
sussman on #svn asked me to bring this up here.
I have three versions of svn installed on various machines, 1.0.4,
1.1.1, and 1.1.3.
Under 1.0.4 I can do:
$ svn ls svn://svn.sablevm.org/sablevm/..
archives/
developers/
libffi/
sablecc/
sablecc-ant-task/
sablecc-grammars/
sablejit/
sablevm/
sablevm-classpath/
sablevm-test-suite/
websites/
but under 1.1.1 and 1.1.3 I get:
$ svn ls svn://svn.sablevm.org/sablevm/..
svn: URL 'svn://svn.sablevm.org/sablevm/..' contains a '..' element
sussman was incredulous about this, saying that for some reason in 1.0
'..' is being accepted deeper in the code, but that validation of URL's
in 1.1 is rejected the command.
Personally, I used this accidental feature a lot, because I would often
use an exported bash variable to save typing, and then simply append /..
to it, e.g.:
$ svn log $STAGING/..
instead of
$ svn log svn+ssh://svn.sablevm.org/public/sablevm/branches/staging/..
so ... I guess this mail serves two purposes:
1) bring this to your attention
2) request that you allow for '..' in a URL again if it isn't a security
hole
I'm not sure what version of svn is running on the server, but I can
find out if you want.
Cheers,
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn URL's with '..' elements
Posted by Chris Pickett <ch...@mail.mcgill.ca>.
Chris Pickett wrote:
> Vincent Lefevre wrote:
>
>> On 2005-02-24 11:08:59 -0800, Ben Reser wrote:
>>
>>> Firefox gives /home/breser if you ask fore
>>> file:///home/breser/foo-tmp/..
>>
>>
>>
>> Ditto for Mozilla, links and w3m. However lynx gives the root directory,
>> but IMHO this is a bug. The .. rule for URLs is described for relative
>> URLs only (RFCs 1808 and 2396), but for consistency, it would be a good
>> idea to use this rule for absolute URLs too IMHO.
>
>
> I think saying .. always removes one element from the specified path and
> documenting that clearly would be a good solution.
More specifically, saying that:
1) ./ is prepended to relative paths that do not have it there
2) ./ at the beginning of a path is converted to the same absolute path
pwd gives you, or simply removed if not at the beginning
3) .. then removes one element from the preceding path, and symlinks are
never followed.
4) /.. == /
$ ls -l foo-tmp
lrwxrwxrwx 1 chris users 4 2005-02-28 14:06 foo-tmp -> /tmp
$ svn ls foo-tmp/..
->
svn ls ./foo-tmp/..
->
svn ls /home/chris/foo-tmp/..
->
svn ls /home/chris
As a user, I having svn not follow symlinks is the behaviour I want. If
I have foo-tmp linked to a directory in a WC, then currently:
$ svn ls foo-tmp/..
svn: '.' is not a working copy
$ cd foo-tmp/
svn ls ..
[follows symlink and lists contents]
So I guess either way, there are things here that need to be fixed.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn URL's with '..' elements
Posted by Chris Pickett <ch...@mail.mcgill.ca>.
Vincent Lefevre wrote:
> On 2005-02-24 11:08:59 -0800, Ben Reser wrote:
>
>>Firefox gives /home/breser if you ask fore
>>file:///home/breser/foo-tmp/..
>
>
> Ditto for Mozilla, links and w3m. However lynx gives the root directory,
> but IMHO this is a bug. The .. rule for URLs is described for relative
> URLs only (RFCs 1808 and 2396), but for consistency, it would be a good
> idea to use this rule for absolute URLs too IMHO.
I think saying .. always removes one element from the specified path and
documenting that clearly would be a good solution.
If your shell is going to screw with the path before it gets to svn (by
following symlinks, or by making the .. adjustment for you), that's
going to happen anyway, even if you disallow .. completely within svn.
If not, then you can dictate what happens (and also give a good
disambiguating error message if needed, by printing the name of the path
before and after removal).
Locally, it seems like .. is only rejected by svn if the resultant path
isn't a WC and you issue your command from within a WC and also use a
relative path.
~/temp $ pwd
/home/chris/temp
~/temp $ ls
sablevm
~/temp $ ls sablevm/
AUTHORS INSTALL LICENSE README THANKS
autogen.sh INSTALL-DEVEL Makefile.am regression
types.header
configure.ac java-sablevm.tmpl NEWS src
doc LGPL-2.1 permute-options svn-commit.tmp~
~/temp $ svn ls sablevm/
.indent.pro
AUTHORS
INSTALL
INSTALL-DEVEL
LGPL-2.1
LICENSE
Makefile.am
NEWS
README
THANKS
autogen.sh
configure.ac
doc/
java-sablevm.tmpl
permute-options
regression/
src/
types.header
~/temp $ svn ls sablevm/..
svn: '.' is not a working copy
~/temp $ cd sablevm/
~/temp/sablevm $ svn ls .
.indent.pro
AUTHORS
INSTALL
INSTALL-DEVEL
LGPL-2.1
LICENSE
Makefile.am
NEWS
README
THANKS
autogen.sh
configure.ac
doc/
java-sablevm.tmpl
permute-options
regression/
src/
types.header
~/temp/sablevm $ svn ls ..
svn: Path '..' ends in '..', which is unsupported for this operation
~/temp/sablevm $ svn ls ../sablevm
.indent.pro
AUTHORS
INSTALL
INSTALL-DEVEL
LGPL-2.1
LICENSE
Makefile.am
NEWS
README
THANKS
autogen.sh
configure.ac
doc/
java-sablevm.tmpl
permute-options
regression/
src/
types.header
~/temp/sablevm $ cd src/
~/temp/sablevm/src $ svn ls
Makefile.am
include/
libsablevm/
sablevm/
spmt/
~/temp/sablevm/src $ svn ls ..
.indent.pro
AUTHORS
INSTALL
INSTALL-DEVEL
LGPL-2.1
LICENSE
Makefile.am
NEWS
README
THANKS
autogen.sh
configure.ac
doc/
java-sablevm.tmpl
permute-options
regression/
src/
types.header
~/temp/sablevm/src $ svn ls ../src/..
.indent.pro
AUTHORS
INSTALL
INSTALL-DEVEL
LGPL-2.1
LICENSE
Makefile.am
NEWS
README
THANKS
autogen.sh
configure.ac
doc/
java-sablevm.tmpl
permute-options
regression/
src/
types.header
~/temp/sablevm/src $ svn ls ../..
svn: Path '../..' ends in '..', which is unsupported for this operation
~/temp/sablevm/src $ svn ls /home/chris/temp/sablevm/src/../..
svn: '/home/chris/temp' is not a working copy
~/temp/sablevm/src $ svn ls file:///home/chris/temp/sablevm/
svn: Unable to open an ra_local session to URL
svn: Unable to open repository 'file:///home/chris/temp/sablevm'
~/temp/sablevm/src $ svn ls file:///home/chris/temp/sablevm/..
svn: URL 'file:///home/chris/temp/sablevm/..' contains a '..' element
Cheers,
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn URL's with '..' elements
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2005-02-24 11:08:59 -0800, Ben Reser wrote:
> Firefox deals with file:/// URLs but users don't use it that often and
> it's not nearly as critical that it work right. But even various
> command line tools don't implement it consistently:
Command line tools work on the Unix file system. URLs are different.
> $ ls -l /home/breser/foo-tmp
> lrwxrwxrwx 1 breser breser 4 Feb 24 11:01
> /home/breser/foo-tmp -> /tmp/
>
> $ (cd /home/breser/foo-tmp/../; pwd)
> /home/breser
>
> $ ls -l /home/breser/foo-tmp/../
> total 27
> drwxr-xr-x 2 root root 2456 Jan 30 2004 bin/
> drwxr-xr-x 3 root root 2056 Feb 21 22:58 boot/
> drwxr-xr-x 1 root root 0 Dec 31 1969 dev/
> [snip]
>
> i.e. the root partition.
ay:~> ls -lg /home/lefevre/foo-tmp
lrwxrwxrwx 1 lefevre 4 2005-02-28 04:56:13 /home/lefevre/foo-tmp -> /tmp/
ay:~> (cd /home/lefevre/foo-tmp/../; pwd)
/
ay:~> ls -l /home/lefevre/foo-tmp/../
total 116
drwxr-xr-x 2 root root 4096 2003-09-08 02:11:46 backup/
[...]
zsh rules!
> Firefox gives /home/breser if you ask fore
> file:///home/breser/foo-tmp/..
Ditto for Mozilla, links and w3m. However lynx gives the root directory,
but IMHO this is a bug. The .. rule for URLs is described for relative
URLs only (RFCs 1808 and 2396), but for consistency, it would be a good
idea to use this rule for absolute URLs too IMHO.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn URL's with '..' elements
Posted by Ben Reser <be...@reser.org>.
On Wed, Feb 23, 2005 at 12:50:03PM -0500, Chris Pickett wrote:
> Ok, well thanks for the explanations. From my perspective:
>
> 1) Firefox understands '..' in URL's, and so does wget, and probably so
> do a number of other common programs (I didn't try any others).
>
> 2) As I stated before, it helps to have '..' if you use environment
> variables in your shell to save typing.
>
> 3) It's kind of frustrating because '..' is allowed if I'm using it to
> refer to a working copy (as recent as 1.1.3).
>
> 4) IMO confusing the user because the error message might not match the
> input is not such a big problem and could be prevented by giving more
> verbose output as to what's going on in the event of an error.
>
> 5) As for extending the URI standard, all that's being asked for is to
> recognize '..' as a directory name, not everything that my shell (bash)
> understands.
>
> So, if you can work around the oher issues you've stated here (problems
> with externals, canonicalizing input, possible buffer underflows), I
> think there's evidence from other projects to suggest this is useful.
> I'll file an RFE (P5) if you like and if there's a chance you'll address
> this in the future. I understand it's not a very high priority.
The other thing that I had forgotten about which Josh brought up is the
symlink issue. I said it didn't matter for URLs but I was forgetting
file:/// URIs. Which are essentially local paths. When a .. is used
and a symlink is in the path it's completly ambiguous as to how to deal
with that. Should we just remove one path element or walk the path?
You can file an issue if you want. But I don't think we should fix this
because the issues are too big of a mess. I understand how it's handy.
But the use of it is ambigous.
Firefox deals with file:/// URLs but users don't use it that often and
it's not nearly as critical that it work right. But even various
command line tools don't implement it consistently:
$ ls -l /home/breser/foo-tmp
lrwxrwxrwx 1 breser breser 4 Feb 24 11:01
/home/breser/foo-tmp -> /tmp/
$ (cd /home/breser/foo-tmp/../; pwd)
/home/breser
$ ls -l /home/breser/foo-tmp/../
total 27
drwxr-xr-x 2 root root 2456 Jan 30 2004 bin/
drwxr-xr-x 3 root root 2056 Feb 21 22:58 boot/
drwxr-xr-x 1 root root 0 Dec 31 1969 dev/
[snip]
i.e. the root partition.
Firefox gives /home/breser if you ask fore
file:///home/breser/foo-tmp/..
It's stuff like this that makes me think we shouldn't implement it...
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn URL's with '..' elements
Posted by Dale Worley <dw...@pingtel.com>.
> From: Chris Pickett [mailto:chris.pickett@mail.mcgill.ca]
>
> 1) Firefox understands '..' in URL's, and so does wget, and
> probably so
> do a number of other common programs (I didn't try any others).
That's derived from the fact that there's a standard regarding how a
relative URL starting with ".." is to be interpreted -- Firefox, wget, et
al. *remove* the ..'s before sending them to the server. (Which defines the
semantics of ".." to be "remove the preceding component of the URL". But on
the server side, there are other possibilities, so the semantics is more
ambiguous.)
It may be that we want a Subversion client to do a similar removal. But by
implication, we would still want to forbid ".." in svn:externals and the
like, since they must have the same meaning for all clients.
Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn URL's with '..' elements
Posted by Chris Pickett <ch...@mail.mcgill.ca>.
Ben Reser wrote:
> On Tue, Feb 22, 2005 at 09:41:23PM -0500, Josh Pieper wrote:
>
>>Those reasons, plus it has not well-defined symantics when used over
>>symlinks. I have some IRC discussions from last July where the merits
>>were discussed if anyone is interested.
>
>
> Ohh yeah forgot about the symlink issue. But the symlink issue doesn't
> apply to URLs. But right now we're using the same functions to
> canonicalize URLs and local file paths so that's why it matters for
> those that wonder.
>
Ok, well thanks for the explanations. From my perspective:
1) Firefox understands '..' in URL's, and so does wget, and probably so
do a number of other common programs (I didn't try any others).
2) As I stated before, it helps to have '..' if you use environment
variables in your shell to save typing.
3) It's kind of frustrating because '..' is allowed if I'm using it to
refer to a working copy (as recent as 1.1.3).
4) IMO confusing the user because the error message might not match the
input is not such a big problem and could be prevented by giving more
verbose output as to what's going on in the event of an error.
5) As for extending the URI standard, all that's being asked for is to
recognize '..' as a directory name, not everything that my shell (bash)
understands.
So, if you can work around the oher issues you've stated here (problems
with externals, canonicalizing input, possible buffer underflows), I
think there's evidence from other projects to suggest this is useful.
I'll file an RFE (P5) if you like and if there's a chance you'll address
this in the future. I understand it's not a very high priority.
Cheers,
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn URL's with '..' elements
Posted by Ben Reser <be...@reser.org>.
On Tue, Feb 22, 2005 at 09:41:23PM -0500, Josh Pieper wrote:
> Those reasons, plus it has not well-defined symantics when used over
> symlinks. I have some IRC discussions from last July where the merits
> were discussed if anyone is interested.
Ohh yeah forgot about the symlink issue. But the symlink issue doesn't
apply to URLs. But right now we're using the same functions to
canonicalize URLs and local file paths so that's why it matters for
those that wonder.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn URL's with '..' elements
Posted by Josh Pieper <jj...@pobox.com>.
Ben Reser wrote:
> On Tue, Feb 22, 2005 at 06:44:52PM -0500, Chris Pickett wrote:
> > sussman on #svn asked me to bring this up here.
> >
> > I have three versions of svn installed on various machines, 1.0.4,
> > 1.1.1, and 1.1.3.
> >
> > so ... I guess this mail serves two purposes:
> >
> > 1) bring this to your attention
> > 2) request that you allow for '..' in a URL again if it isn't a security
> > hole
> >
> > I'm not sure what version of svn is running on the server, but I can
> > find out if you want.
>
> We had support for this briefly, I think maybe one release, but IIRC
> removed it for these reasons:
>
> * Despite common usage .. doesn't have any special meaning per the URI
> standard.
> * Because we canonicalize URLs on input it could create confusing
> results. In particular if the resulting path didn't exist the URL we
> said didn't exist wouldn't match what the user requested.
> * The behavior is undefined when dealing with no-op path elements e.g.
> //. Should we remove it or not.
> * Caused some sort of issues with externals.
> * Were more trouble than they were worth to make function safely (e.g.
> buffer underflows).
>
> jpieper is the one who specificially removed the functionality perhaps
> he can be specific or correct me if I'm remembering wrong.
Those reasons, plus it has not well-defined symantics when used over
symlinks. I have some IRC discussions from last July where the merits
were discussed if anyone is interested.
-Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn URL's with '..' elements
Posted by Ben Reser <be...@reser.org>.
On Tue, Feb 22, 2005 at 06:44:52PM -0500, Chris Pickett wrote:
> sussman on #svn asked me to bring this up here.
>
> I have three versions of svn installed on various machines, 1.0.4,
> 1.1.1, and 1.1.3.
>
> Under 1.0.4 I can do:
>
> $ svn ls svn://svn.sablevm.org/sablevm/..
> archives/
> developers/
> libffi/
> sablecc/
> sablecc-ant-task/
> sablecc-grammars/
> sablejit/
> sablevm/
> sablevm-classpath/
> sablevm-test-suite/
> websites/
>
> but under 1.1.1 and 1.1.3 I get:
>
> $ svn ls svn://svn.sablevm.org/sablevm/..
> svn: URL 'svn://svn.sablevm.org/sablevm/..' contains a '..' element
>
> sussman was incredulous about this, saying that for some reason in 1.0
> '..' is being accepted deeper in the code, but that validation of URL's
> in 1.1 is rejected the command.
>
> Personally, I used this accidental feature a lot, because I would often
> use an exported bash variable to save typing, and then simply append /..
> to it, e.g.:
>
> $ svn log $STAGING/..
>
> instead of
>
> $ svn log svn+ssh://svn.sablevm.org/public/sablevm/branches/staging/..
>
> so ... I guess this mail serves two purposes:
>
> 1) bring this to your attention
> 2) request that you allow for '..' in a URL again if it isn't a security
> hole
>
> I'm not sure what version of svn is running on the server, but I can
> find out if you want.
We had support for this briefly, I think maybe one release, but IIRC
removed it for these reasons:
* Despite common usage .. doesn't have any special meaning per the URI
standard.
* Because we canonicalize URLs on input it could create confusing
results. In particular if the resulting path didn't exist the URL we
said didn't exist wouldn't match what the user requested.
* The behavior is undefined when dealing with no-op path elements e.g.
//. Should we remove it or not.
* Caused some sort of issues with externals.
* Were more trouble than they were worth to make function safely (e.g.
buffer underflows).
jpieper is the one who specificially removed the functionality perhaps
he can be specific or correct me if I'm remembering wrong.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org