You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Vincent Lefevre <vi...@vinc17.net> on 2022/10/24 13:57:44 UTC
[BUG] svn tries to read a directory on a different filesystem and hangs
"svn" goes up in the directory hierarchy to look for a .svn directory.
The issue is that it doesn't stop at filesystem and/or owner change.
This has several consequences:
* A potential security issue, because some .svn directory may be
under control of another user.
* On some machine at my lab (Debian/stable), this makes svn hang
when trying to open "/home/.svn", which is the home dir of the
user ".svn" (FYI, emacs tries to get the svn status of a file
when opening it).
This is reproducible with
svn, version 1.14.2 (r1899510)
compiled Oct 20 2022, 08:12:24 on x86_64-pc-linux-gnu
under Debian/unstable.
On the Debian/stable machine, this issue is made worse by the fact
that svn still goes up after a svn working copy has been reached:
patate:~/private/backup> svn info
hangs, but not
patate:~/private> svn info
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at '/home/vlefevre/private'
is too old (format 9) to work with client version '1.14.1 (r1886195)' (expects format 31). You need to upgrade the working copy first.
which fails immediately (this was probably a very old svn working copy,
which I no longer use).
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: [BUG] svn tries to read a directory on a different filesystem and hangs
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2022-11-06 04:59:19 +0100, Vincent Lefevre wrote:
> I'm also wondering of the consequence of symlinks .svn/entries to
> /path-to-attacked-user/.svn/entries, etc. except for the pristine
> subdirectory, which Mallory creates as world-writable. If the user
> does a "svn up", could this populate the pristine subdirectory
> (owned by Mallory)?
In case this is not clear:
Mallory owns the "/home/.svn" directory.
The user's home is "/home/user".
The user has a working copy "/home/user/private-wc" and Mallory knows
that (or at least can guess).
The symlinks would be:
/home/.svn/entries -> /home/user/private-wc/.svn/entries
and ditto for "format", "tmp", "wc.db", "wc.db-journal".
Actually this doesn't seem to work as svn expects .svn-base files
(with a test using ~/software/test/.svn instead of /home/.svn):
zira:~/software/test> svn up
svn: E155009: Failed to run the WC DB work queue associated with '/home/vinc17/software/test/README', work item 2510 (file-install README 1 0 1 1)
svn: E000002: Can't open file '/home/vinc17/software/test/.svn/pristine/41/412b65baed0c5ba451a7151c8630c135b6116557.svn-base': No such file or directory
However, this modifies the user's working copy (which shouldn't have
been touched), as "svn up" gives from this working copy:
svn: E155037: Previous operation has not finished; run 'cleanup' if it was interrupted
This is bad.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: [BUG] svn tries to read a directory on a different filesystem and hangs
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2022-10-31 10:02:14 +0000, Daniel Shahaf wrote:
> Vincent Lefevre wrote on Mon, 24 Oct 2022 13:57 +00:00:
> > "svn" goes up in the directory hierarchy to look for a .svn directory.
> > The issue is that it doesn't stop at filesystem and/or owner change.
>
> Why should the upwards scan stop at mount points? Because accessing
> /home/.svn on a random machine in your lab hangs? That's insufficient
> justification.
There's also a potential security issue if the owner is different,
and that basically the same as below:
> Why should the upwards scan stop at owner change? What's the facts of
> the setup (a concrete example with relevant ownerships and permissions
> specified) and what could Mallory do that he shouldn't be able to? Feel
> free to reply on security@ if the matter isn't suitable for public
> discussion.
I don't have to do much testing at the moment, but some ideas...
Mallory could set up a .svn directory he controls. So if one does
"svn info", that would output a last changed author that Mallory
chose. Now, does the svn client check whether there are non-printable
characters in the author name? If it doesn't, this could send escape
sequences to the terminal.
I'm also wondering of the consequence of symlinks .svn/entries to
/path-to-attacked-user/.svn/entries, etc. except for the pristine
subdirectory, which Mallory creates as world-writable. If the user
does a "svn up", could this populate the pristine subdirectory
(owned by Mallory)?
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: [BUG] svn tries to read a directory on a different filesystem and hangs
Posted by Daniel Sahlberg <da...@gmail.com>.
Den sön 13 nov. 2022 06:10Nathan Hartman <ha...@gmail.com> skrev:
> On Fri, Nov 11, 2022 at 3:58 PM Daniel Shahaf <d....@daniel.shahaf.name>
> wrote:
>
>> Daniel Shahaf wrote on Mon, Oct 31, 2022 at 10:02:14 +0000:
>> > Vincent Lefevre wrote on Mon, 24 Oct 2022 13:57 +00:00:
>> > > "svn" goes up in the directory hierarchy to look for a .svn directory.
>> > > The issue is that it doesn't stop at filesystem and/or owner change.
>> >
>> > Why should the upwards scan stop at mount points? Because accessing
>> > /home/.svn on a random machine in your lab hangs? That's insufficient
>> > justification.
>
>
>
> FWIW git stops scanning upwards at a filesystem boundary by default; IIRC
> some command line switch overrides that. I don't have example output handy
> (writing this on my phone).
>
>
> Because if the .svn directory were on a different mount point,
>> a subsequent «svn update» might attempt to atomically rename(2) something
>> from .svn/ into the ACTUAL tree, and fail because they're not on the
>> same device?
>>
>> Example: If /h/home is a mountpoint and jrandom does 'svn up' in
>> /h/home/jrandom, then even if /h/.svn exists, atomic renames from
>> /h/.svn/tmp/foo to /h/home/jrandom/path/to/wc/bar wouldn't be possible.
>> Is this a good reason not to look for /h/.svn or /.svn at all (i.e., to
>> recurse upwards no further than to /h/home/.svn)?
>>
>
I tried to do it but failed, as Danielsh suspected above:
[[[
Updating '.':
svn: E155009: Failed to run the WC DB work queue associated with
'/home/dsg/multimntpntwc/foo/file.txt', work item 5 (file-install
foo/file.txt 1 0 1 1)
svn: E000018: Can't move '/home/dsg/multimntpntwc/.svn/tmp/svn-p5XxYe' to
'/home/dsg/multimntpntwc/foo/file.txt': Invalid cross-device link
]]]
In my example, I created multimntpntwc/foo and checked out a filesystem on
foo. Then I tried to checkout on to the non-empty directory.
On Windows, with foo being a directory junction pointing to a directory on
another disk, it fails with a similar error message: "Unable to move the
file to another disk drive" <my translation from Swedish>.
How could a working copy end up spanning filesystems? I can think of two
> ways: (1) a checkout into a non-empty directory, in which some subdirectory
> is a mountpoint; if that subdirectory shares the same path as a versioned
> subdirectory, the former will occlude the latter. Or (2) a user checks out
> a working copy and then mounts a filesystem onto one of the subdirectories.
>
> Is there a reasonable use case for doing either of the above?
>
Define reasonable. If the wc is too large to fit on one device, you could
mount a separate device within the WC tree. As far as I understand (1) it
doesn't work right now and (2) you would need to jump through hoops to
create such structure. Therefor I'm not sure it makes sense to support such
use case.
If we make changes similar to git's behaviour, we need to make sure the
code also works on Windows, detecting directory junctions and symbolic
links.
Kind regards,
/Daniel
Re: [BUG] svn tries to read a directory on a different filesystem and hangs
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Nov 11, 2022 at 3:58 PM Daniel Shahaf <d....@daniel.shahaf.name>
wrote:
> Daniel Shahaf wrote on Mon, Oct 31, 2022 at 10:02:14 +0000:
> > Vincent Lefevre wrote on Mon, 24 Oct 2022 13:57 +00:00:
> > > "svn" goes up in the directory hierarchy to look for a .svn directory.
> > > The issue is that it doesn't stop at filesystem and/or owner change.
> >
> > Why should the upwards scan stop at mount points? Because accessing
> > /home/.svn on a random machine in your lab hangs? That's insufficient
> > justification.
FWIW git stops scanning upwards at a filesystem boundary by default; IIRC
some command line switch overrides that. I don't have example output handy
(writing this on my phone).
Because if the .svn directory were on a different mount point,
> a subsequent «svn update» might attempt to atomically rename(2) something
> from .svn/ into the ACTUAL tree, and fail because they're not on the
> same device?
>
> Example: If /h/home is a mountpoint and jrandom does 'svn up' in
> /h/home/jrandom, then even if /h/.svn exists, atomic renames from
> /h/.svn/tmp/foo to /h/home/jrandom/path/to/wc/bar wouldn't be possible.
> Is this a good reason not to look for /h/.svn or /.svn at all (i.e., to
> recurse upwards no further than to /h/home/.svn)?
>
How could a working copy end up spanning filesystems? I can think of two
ways: (1) a checkout into a non-empty directory, in which some subdirectory
is a mountpoint; if that subdirectory shares the same path as a versioned
subdirectory, the former will occlude the latter. Or (2) a user checks out
a working copy and then mounts a filesystem onto one of the subdirectories.
Is there a reasonable use case for doing either of the above?
Thanks
Nathan
Re: [BUG] svn tries to read a directory on a different filesystem and hangs
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Daniel Shahaf wrote on Mon, Oct 31, 2022 at 10:02:14 +0000:
> Vincent Lefevre wrote on Mon, 24 Oct 2022 13:57 +00:00:
> > "svn" goes up in the directory hierarchy to look for a .svn directory.
> > The issue is that it doesn't stop at filesystem and/or owner change.
>
> Why should the upwards scan stop at mount points? Because accessing
> /home/.svn on a random machine in your lab hangs? That's insufficient
> justification.
Because if the .svn directory were on a different mount point,
a subsequent «svn update» might attempt to atomically rename(2) something
from .svn/ into the ACTUAL tree, and fail because they're not on the
same device?
Example: If /h/home is a mountpoint and jrandom does 'svn up' in
/h/home/jrandom, then even if /h/.svn exists, atomic renames from
/h/.svn/tmp/foo to /h/home/jrandom/path/to/wc/bar wouldn't be possible.
Is this a good reason not to look for /h/.svn or /.svn at all (i.e., to
recurse upwards no further than to /h/home/.svn)?
Re: [BUG] svn tries to read a directory on a different filesystem and hangs
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Vincent Lefevre wrote on Mon, 24 Oct 2022 13:57 +00:00:
> "svn" goes up in the directory hierarchy to look for a .svn directory.
> The issue is that it doesn't stop at filesystem and/or owner change.
Why should the upwards scan stop at mount points? Because accessing
/home/.svn on a random machine in your lab hangs? That's insufficient
justification.
Why should the upwards scan stop at owner change? What's the facts of
the setup (a concrete example with relevant ownerships and permissions
specified) and what could Mallory do that he shouldn't be able to? Feel
free to reply on security@ if the matter isn't suitable for public
discussion.
> This has several consequences:
>
> * A potential security issue, because some .svn directory may be
> under control of another user.
>
> * On some machine at my lab (Debian/stable), this makes svn hang
> when trying to open "/home/.svn", which is the home dir of the
> user ".svn" (FYI, emacs tries to get the svn status of a file
> when opening it).
>
> This is reproducible with
>
> svn, version 1.14.2 (r1899510)
> compiled Oct 20 2022, 08:12:24 on x86_64-pc-linux-gnu
>
> under Debian/unstable.
>
> On the Debian/stable machine, this issue is made worse by the fact
> that svn still goes up after a svn working copy has been reached:
>
> patate:~/private/backup> svn info
>
> hangs, but not
>
> patate:~/private> svn info
> svn: E155036: Please see the 'svn upgrade' command
> svn: E155036: The working copy at '/home/vlefevre/private'
> is too old (format 9) to work with client version '1.14.1 (r1886195)'
> (expects format 31). You need to upgrade the working copy first.
>
> which fails immediately (this was probably a very old svn working copy,
> which I no longer use).
Not everyone uses Debian, so saying "the version of svn in Debian
stable" is farther right on the https://xkcd.com/1343/ scale than it
could be. Distro version number and codename and package version
number is what I'd recommend.
Cheers,
Daniel
> --
> Vincent Lefèvre <vi...@vinc17.net> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)