FAQ

[Subversion-users] Very big problems with access rights (authz file using) in SVN v1.7.0

Andrey
Oct 18, 2011 at 10:08 am
Hello!

We had upgraded from SVN v1.6.5 to SVN v1.7.0, and now we have a
really big problems, because SVN v1.7.0 is not working as previous SVN
versions and incorrectly working with restrictions for some
directories in authz.

A simple example of the issue:

Let's assume this authz file:
===================================================
[repos:/PROJECT/trunk/Sample]
ax = rw
mh = rw
lk = rw
sa = r
ep = rw

[repos:/PROJECT/trunk/Sample/AnyDir/RestrictedDir]
ax = rw
mh = rw
* =
===================================================

SVN v1.6.5 and all clients worked with it in the following manner:
1. They are allowed to use 'svn update' command on the "Sample" directory.
2. They are showed "Sample/AnyDir/RestrictedDir" in repo-browser
(TortoiseSVN GUI), but did not allowed to update/commit or view
content of this directory.
3. There are no any problems to make svn update in any part of the
"/Sample" dir and subdirs using svn client (command line) or any
other (GUI) client.

After upgrading our server to SVN v1.7.0 we had a really big problems,
because now when we try to make update in the root directory (/Sample)
we see something like:

========================================================================
Updating '.': 13:5
Restored 'Sample\AnyDir\RestrictedDir'
svn: E155000: Failed to mark 'D:\BUILD_ROOT\PROJECT\trunk\Sample\AnyDir\RestrictedDir'
absent: item of the same name is already scheduled for addition
========================================================================

So, SVN update failed!

No we cannot use our BUILD SERVER, also coders are unable to make SVN
UPDATE locally with the same problem!

We have a complicated access rules for different users. Now it does
not work AT ALL! Because if some directory is available for user to
see that it is exist (it is made to give a possibility to make a
commits in a root directory, and do not split commits to a few dirs),
he will unable to make svn update in the root -- svn will fail on this
directory, that must be easly skipped, as SVN v1.6.5 server/clients
done before!

This is a really serious problem for us, we can't work now.

-- FTSOS
Andrey mailto:andrey@online-solutions.ru
reply

Search Discussions

14 responses

  • Stefan Sperling at Oct 18, 2011 at 10:55 am

    On Tue, Oct 18, 2011 at 01:54:20PM +0400, Andrey wrote:
    ========================================================================
    Updating '.': 13:5
    Restored 'Sample\AnyDir\RestrictedDir'
    svn: E155000: Failed to mark 'D:\BUILD_ROOT\PROJECT\trunk\Sample\AnyDir\RestrictedDir'
    absent: item of the same name is already scheduled for addition
    ========================================================================

    So, SVN update failed!
    This looks like a bug. Thanks for reporting it.
    No we cannot use our BUILD SERVER, also coders are unable to make SVN
    UPDATE locally with the same problem!

    We have a complicated access rules for different users. Now it does
    not work AT ALL! Because if some directory is available for user to
    see that it is exist (it is made to give a possibility to make a
    commits in a root directory, and do not split commits to a few dirs),
    he will unable to make svn update in the root -- svn will fail on this
    directory, that must be easly skipped, as SVN v1.6.5 server/clients
    done before!

    This is a really serious problem for us, we can't work now.
    And you have no way of falling back to 1.6 until the problem gets analyzed
    and fixed? That's an irresponsible way of upgrading a critical piece of
    your software infrastructure.

    It's bad that this problem didn't get found during pre-release testing.
    But that's a fact of life. Some problems will always slip through into
    a new release, and you should be prepared in case you run into them.

    The best you can hope for is to get a fix in 1.7.1, which is still
    at least a week or 2 away from being released. In the meantime, if
    you cannot work with 1.7.0, please use 1.6.17.
  • Bert Huijben at Oct 18, 2011 at 12:43 pm

    -----Original Message-----
    From: Andrey
    Sent: dinsdag 18 oktober 2011 11:54
    To: users@subversion.apache.org
    Subject: Very big problems with access rights (authz file using) in SVN v1.7.0
    Importance: High

    Hello!

    We had upgraded from SVN v1.6.5 to SVN v1.7.0, and now we have a
    really big problems, because SVN v1.7.0 is not working as previous SVN
    versions and incorrectly working with restrictions for some
    directories in authz.

    A simple example of the issue:

    Let's assume this authz file:
    ===================================================
    [repos:/PROJECT/trunk/Sample]
    ax = rw
    mh = rw
    lk = rw
    sa = r
    ep = rw

    [repos:/PROJECT/trunk/Sample/AnyDir/RestrictedDir]
    ax = rw
    mh = rw
    * =
    ===================================================

    SVN v1.6.5 and all clients worked with it in the following manner:
    1. They are allowed to use 'svn update' command on the "Sample" directory.
    2. They are showed "Sample/AnyDir/RestrictedDir" in repo-browser
    (TortoiseSVN GUI), but did not allowed to update/commit or view
    content of this directory.
    3. There are no any problems to make svn update in any part of the
    "/Sample" dir and subdirs using svn client (command line) or any
    other (GUI) client.

    After upgrading our server to SVN v1.7.0 we had a really big problems,
    because now when we try to make update in the root directory (/Sample)
    we see something like:

    ==========================================================
    ==============
    Updating '.': 13:5
    Restored 'Sample\AnyDir\RestrictedDir'
    svn: E155000: Failed to mark
    'D:\BUILD_ROOT\PROJECT\trunk\Sample\AnyDir\RestrictedDir'
    absent: item of the same name is already scheduled for addition
    ==========================================================
    ==============

    So, SVN update failed!

    No we cannot use our BUILD SERVER, also coders are unable to make SVN
    UPDATE locally with the same problem!

    We have a complicated access rules for different users. Now it does
    not work AT ALL! Because if some directory is available for user to
    see that it is exist (it is made to give a possibility to make a
    commits in a root directory, and do not split commits to a few dirs),
    he will unable to make svn update in the root -- svn will fail on this
    directory, that must be easly skipped, as SVN v1.6.5 server/clients
    done before!

    This is a really serious problem for us, we can't work now.
    Can you post a simple walkthrough script that describes your exact problem.

    By just reading your mail I would guess the script is:

    As user lk do:

    $ svn co http://server/repos/PROJECT/trunk/Sample sample
    $ svn up sample
    (repeat the update)

    But this simple scenario appears to work correctly for me as it doesn't
    check out AnyDir/RestrictedDir in my tests.

    The ouput of svn says that you update the directory above 'Sample'.


    Things I'm interested in are like:
    * Do multiple users share a single working copy?
    So AnyDir/restricteddir is checked out by one user, but wouldn't be by the
    user updating. Or the other way around.

    * Is the configuration changed between updates?
    Is some change in a specific location required between updates?
    E.g. one in AnyDir, RestrictedDir, etc.

    I can see some problems, which might need fixing but I'm still not sure what
    your specific problem is.
    (I'm not sure if the problems I currently see are regressions. Still looking
    into that)


    The error you see would only make sense if the working copy doesn't know
    about RestrictedDir, except that it is a locally added file or directory.
    When the server then tells that there should be a restricted path there you
    get this error.

    But giving a working copy with a single user, that is +- impossible to read
    in your mail.

    Bert
  • Andrey at Oct 18, 2011 at 1:11 pm
    Hello.
    We had upgraded from SVN v1.6.5 to SVN v1.7.0, and now we have a
    really big problems, because SVN v1.7.0 is not working as previous SVN
    versions and incorrectly working with restrictions for some
    directories in authz.

    A simple example of the issue:

    Let's assume this authz file:
    ===================================================
    [repos:/PROJECT/trunk/Sample]
    ax = rw
    mh = rw
    lk = rw
    sa = r
    ep = rw

    [repos:/PROJECT/trunk/Sample/AnyDir/RestrictedDir]
    ax = rw
    mh = rw
    * =
    ===================================================

    SVN v1.6.5 and all clients worked with it in the following manner:
    1. They are allowed to use 'svn update' command on the "Sample" directory.
    2. They are showed "Sample/AnyDir/RestrictedDir" in repo-browser
    (TortoiseSVN GUI), but did not allowed to update/commit or view
    content of this directory.
    3. There are no any problems to make svn update in any part of the
    "/Sample" dir and subdirs using svn client (command line) or any
    other (GUI) client.

    After upgrading our server to SVN v1.7.0 we had a really big problems,
    because now when we try to make update in the root directory (/Sample)
    we see something like:

    ==========================================================
    ==============
    Updating '.': 13:5
    Restored 'Sample\AnyDir\RestrictedDir'
    svn: E155000: Failed to mark
    'D:\BUILD_ROOT\PROJECT\trunk\Sample\AnyDir\RestrictedDir'
    absent: item of the same name is already scheduled for addition
    ==========================================================
    ==============

    So, SVN update failed!

    No we cannot use our BUILD SERVER, also coders are unable to make SVN
    UPDATE locally with the same problem!

    We have a complicated access rules for different users. Now it does
    not work AT ALL! Because if some directory is available for user to
    see that it is exist (it is made to give a possibility to make a
    commits in a root directory, and do not split commits to a few dirs),
    he will unable to make svn update in the root -- svn will fail on this
    directory, that must be easly skipped, as SVN v1.6.5 server/clients
    done before!

    This is a really serious problem for us, we can't work now.
    BH> Can you post a simple walkthrough script that describes your exact problem.

    BH> By just reading your mail I would guess the script is:

    BH> As user lk do:

    BH> $ svn co http://server/repos/PROJECT/trunk/Sample sample
    BH> $ svn up sample
    BH> (repeat the update)

    BH> But this simple scenario appears to work correctly for me as it doesn't
    BH> check out AnyDir/RestrictedDir in my tests.

    BH> The ouput of svn says that you update the directory above 'Sample'.

    Users, who have no access to "RestrictedDir" have such local copies
    (just sample):

    C:/PROJECT/trunk/Sample

    C:/PROJECT/trunk/Sample/SomeDirForEveryone
    C:/PROJECT/trunk/Sample/SomeDirForEveryone/DummyFile.txt
    C:/PROJECT/trunk/Sample/SomeDirForEveryone/DummyFile.bin

    C:/PROJECT/trunk/Sample/AnotherDir
    C:/PROJECT/trunk/Sample/AnotherDir/DummyFile2.cpp
    C:/PROJECT/trunk/Sample/AnotherDir/DummyFile2.h

    C:/PROJECT/trunk/Sample/AnyDir
    C:/PROJECT/trunk/Sample/AnyDir/AccessableDir
    C:/PROJECT/trunk/Sample/AnyDir/AccessableDir/AccessableFile.txt
    C:/PROJECT/trunk/Sample/AnyDir/AccessableDir/AccessableFile.bin
    C:/PROJECT/trunk/Sample/AnyDir/AccessableDir2
    C:/PROJECT/trunk/Sample/AnyDir/AccessableDir2/AccessableFile.txt
    C:/PROJECT/trunk/Sample/AnyDir/AccessableDir2/AccessableFile.bin

    C:/PROJECT/trunk/Sample/AnotherDir3
    C:/PROJECT/trunk/Sample/AnotherDir3/DummyFile2.cpp
    C:/PROJECT/trunk/Sample/AnotherDir3/DummyFile2.h

    Users (who are restricted to access RestrictedDir) does not have local
    copy of
    C:/PROJECT/trunk/Sample/AnyDir/RestrictedDir

    Previous behaviour (SVN v1.6.5 CollabNet / TortoiseSVN v1.6.15/16/other, prior v1.7.0):
    When user use svn update into C:/PROJECT/trunk/Sample directory, it
    receives updates for any files/directories of this
    directory/subdirectories, EXCLUDING anything, that are subdir/subfiles
    for
    C:/PROJECT/trunk/Sample/AnyDir/RestrictedDir

    Users can see that this directory exist (through repo-browser of
    TortoiseSVN, for example), because they have access for RW to /Sample
    dir, but most of them (except 'ax' and 'mh') CANNOT list or receive
    (read/write) files from/to this directory, because it is restricted by
    "* =" rule.

    So, it is a perfect way to allow for most users do update and commits
    from a root directory (/Sample) (we providing a 'powerful' rights on
    root, but removing some rights for restricted dirs only).

    But when we using SVN v1.7.0 (console client from the same build as
    server; or TortoiseSVN), we had a problem. When user (who is
    restricted to access /RestrictedDir) tries to make svn update on the
    root dir (/Sample), he got error as I described above.

    Updating '.'
    Restored 'Sample\AnyDir\RestrictedDir'
    svn: E155000: Failed to mark 'D:\BUILD_ROOT\PROJECT\trunk\Sample\AnyDir\RestrictedDir'
    absent: item of the same name is already scheduled for addition

    SVN does not skip this directory, it creates is locally(!) as empty
    directory(!) and stop/fail on svn update after this.

    That's all.

    (Previous versions just skipped this directory, because they are
    checked that user have no access to this directory; they did not
    created an empty dirs; just skipped without any errors).

    BH> Things I'm interested in are like:

    BH> * Do multiple users share a single working copy?

    No.

    BH> So AnyDir/restricteddir is checked out by one user, but wouldn't be by the
    BH> user updating. Or the other way around.

    BH> * Is the configuration changed between updates?

    No.

    BH> Is some change in a specific location required between updates?
    BH> E.g. one in AnyDir, RestrictedDir, etc.

    BH> I can see some problems, which might need fixing but I'm still not sure what
    BH> your specific problem is.
    BH> (I'm not sure if the problems I currently see are regressions. Still looking
    BH> into that)

    BH> The error you see would only make sense if the working copy doesn't know
    BH> about RestrictedDir, except that it is a locally added file or directory.
    BH> When the server then tells that there should be a restricted path there you
    BH> get this error.

    BH> But giving a working copy with a single user, that is +- impossible to read
    BH> in your mail.

    --
    С уважением,
    Andrey mailto:andrey@online-solutions.ru
  • Stefan Sperling at Oct 18, 2011 at 1:21 pm

    On Tue, Oct 18, 2011 at 05:09:52PM +0400, Andrey wrote:
    But when we using SVN v1.7.0 (console client from the same build as
    server; or TortoiseSVN), we had a problem. When user (who is
    restricted to access /RestrictedDir) tries to make svn update on the
    root dir (/Sample), he got error as I described above.

    Updating '.'
    Restored 'Sample\AnyDir\RestrictedDir'
    svn: E155000: Failed to mark 'D:\BUILD_ROOT\PROJECT\trunk\Sample\AnyDir\RestrictedDir'
    absent: item of the same name is already scheduled for addition

    SVN does not skip this directory, it creates is locally(!) as empty
    directory(!) and stop/fail on svn update after this.

    That's all.
    Can you please clarify which versions were running on the client
    and which version was running on the server when the problem appeared?

    Both running 1.7?
    Server 1.6 and clients 1.7?
    Clients 1.6 and server 1.7?
    From what you're saying the only thing I understand is that both
    1.6 client and 1.6 server was working.
  • Andrey at Oct 18, 2011 at 1:40 pm
    Здравствуйте, Stefan.

    Вы писали 18 октября 2011 г., 17:20:56:
    But when we using SVN v1.7.0 (console client from the same build as
    server; or TortoiseSVN), we had a problem. When user (who is
    restricted to access /RestrictedDir) tries to make svn update on the
    root dir (/Sample), he got error as I described above.

    Updating '.'
    Restored 'Sample\AnyDir\RestrictedDir'
    svn: E155000: Failed to mark 'D:\BUILD_ROOT\PROJECT\trunk\Sample\AnyDir\RestrictedDir'
    absent: item of the same name is already scheduled for addition

    SVN does not skip this directory, it creates is locally(!) as empty
    directory(!) and stop/fail on svn update after this.

    That's all.
    SS> Can you please clarify which versions were running on the client
    SS> and which version was running on the server when the problem appeared?

    SS> Both running 1.7?
    SS> Server 1.6 and clients 1.7?
    SS> Clients 1.6 and server 1.7?

    SS> From what you're saying the only thing I understand is that both
    SS> 1.6 client and 1.6 server was working.

    All for users, who have no access to restricted dir:

    1. Server: SVN v1.7.0 (WANdisco build)
    Client: TortoiseSVN v1.7.0

    NOT WORKING (update problem; empty directory created, update failed)

    2. Server: SVN v1.7.0 (WANdisco build)
    Client: Console SVN v1.7.0 (WANdisco build)

    NOT WORKING (update problem; empty directory created, update failed)

    3. Server: SVN v1.7.0 (WANdisco build)
    Client: TortoiseSVN v1.6.15 (Subversion v1.6.16)

    [!] WORKING as previous behaviour!

    So, the problem is really inside CLIENT interpretation of server
    statuses. Both new version of console svn.exe (svn client) and
    TortoiseSVN working incorrectly now.

    --
    С уважением,
    Andrey mailto:andrey@online-solutions.ru
  • Johan Corveleyn at Oct 18, 2011 at 1:44 pm

    2011/10/18 Andrey <andrey@online-solutions.ru>:
    Здравствуйте, Stefan.

    Вы писали 18 октября 2011 г., 17:20:56:
    But when we using SVN v1.7.0 (console client from the same build as
    server; or TortoiseSVN), we had a problem. When user (who is
    restricted to access /RestrictedDir) tries to make svn update on the
    root dir (/Sample), he got error as I described above.

    Updating '.'
    Restored 'Sample\AnyDir\RestrictedDir'
    svn: E155000: Failed to mark 'D:\BUILD_ROOT\PROJECT\trunk\Sample\AnyDir\RestrictedDir'
    absent: item of the same name is already scheduled for addition

    SVN does not skip this directory, it creates is locally(!) as empty
    directory(!) and stop/fail on svn update after this.

    That's all.
    SS> Can you please clarify which versions were running on the client
    SS> and which version was running on the server when the problem appeared?

    SS> Both running 1.7?
    SS> Server 1.6 and clients 1.7?
    SS> Clients 1.6 and server 1.7?

    SS> From what you're saying the only thing I understand is that both
    SS> 1.6 client and 1.6 server was working.

    All for users, who have no access to restricted dir:

    1. Server: SVN v1.7.0 (WANdisco build)
    Client: TortoiseSVN v1.7.0

    NOT WORKING (update problem; empty directory created, update failed)

    2. Server: SVN v1.7.0 (WANdisco build)
    Client: Console SVN v1.7.0 (WANdisco build)

    NOT WORKING (update problem; empty directory created, update failed)

    3. Server: SVN v1.7.0 (WANdisco build)
    Client: TortoiseSVN v1.6.15 (Subversion v1.6.16)

    [!] WORKING as previous behaviour!

    So, the problem is really inside CLIENT interpretation of server
    statuses. Both new version of console svn.exe (svn client) and
    TortoiseSVN working incorrectly now.
    Is it broken only for working copies that were upgraded from 1.6 to
    1.7, or also for new checkouts done with your 1.7 client?

    I'm wondering if it's a bug in the upgrade code (server-excluded nodes
    being incorrectly upgraded), or in the general handling of
    server-exluded nodes in 1.7.

    --
    Johan
  • Andrey at Oct 18, 2011 at 1:54 pm
    Здравствуйте, Johan.

    Вы писали 18 октября 2011 г., 17:43:48:

    JC> 2011/10/18 Andrey <andrey@online-solutions.ru>:
    Здравствуйте, Stefan.

    Вы писали 18 октября 2011 г., 17:20:56:
    But when we using SVN v1.7.0 (console client from the same build as
    server; or TortoiseSVN), we had a problem. When user (who is
    restricted to access /RestrictedDir) tries to make svn update on the
    root dir (/Sample), he got error as I described above.

    Updating '.'
    Restored 'Sample\AnyDir\RestrictedDir'
    svn: E155000: Failed to mark 'D:\BUILD_ROOT\PROJECT\trunk\Sample\AnyDir\RestrictedDir'
    absent: item of the same name is already scheduled for addition

    SVN does not skip this directory, it creates is locally(!) as empty
    directory(!) and stop/fail on svn update after this.

    That's all.
    SS> Can you please clarify which versions were running on the client
    SS> and which version was running on the server when the problem appeared?

    SS> Both running 1.7?
    SS> Server 1.6 and clients 1.7?
    SS> Clients 1.6 and server 1.7?

    SS> From what you're saying the only thing I understand is that both
    SS> 1.6 client and 1.6 server was working.

    All for users, who have no access to restricted dir:

    1. Server: SVN v1.7.0 (WANdisco build)
    Client: TortoiseSVN v1.7.0

    NOT WORKING (update problem; empty directory created, update failed)

    2. Server: SVN v1.7.0 (WANdisco build)
    Client: Console SVN v1.7.0 (WANdisco build)

    NOT WORKING (update problem; empty directory created, update failed)

    3. Server: SVN v1.7.0 (WANdisco build)
    Client: TortoiseSVN v1.6.15 (Subversion v1.6.16)

    [!] WORKING as previous behaviour!

    So, the problem is really inside CLIENT interpretation of server
    statuses. Both new version of console svn.exe (svn client) and
    TortoiseSVN working incorrectly now.
    JC> Is it broken only for working copies that were upgraded from 1.6 to
    JC> 1.7, or also for new checkouts done with your 1.7 client?

    JC> I'm wondering if it's a bug in the upgrade code (server-excluded nodes
    JC> being incorrectly upgraded), or in the general handling of
    JC> server-exluded nodes in 1.7.

    Yes, you are right, it is a bug with upgrade procedure.

    I made an expirement:

    1. Made a clean checkout to a new place on a computer of user with
    restricted access. Checkout was without any problem.
    2. After this I tried to make svn update -- all was fine.
    3. After this from my computer I made a "cross" commit (one commit
    includes a change to a files, where users have no access, and to a
    files accessed by them).
    I used SVN update on root directory on restricted-users -- all was
    fine.

    So, if a clean checkout (without upgrade) is made, there is no such
    problem.

    --
    С уважением,
    Andrey mailto:andrey@online-solutions.ru
  • Bert Huijben at Oct 18, 2011 at 5:43 pm

    -----Original Message-----
    From: Andrey
    Sent: dinsdag 18 oktober 2011 15:53
    To: Johan Corveleyn
    Cc: Stefan Sperling; Bert Huijben; users@subversion.apache.org
    Subject: Re[4]: Very big problems with access rights (authz file using) in SVN
    v1.7.0

    Здравствуйте, Johan.

    Вы писали 18 октября 2011 г., 17:43:48:

    JC> 2011/10/18 Andrey <andrey@online-solutions.ru>:
    Здравствуйте, Stefan.

    Вы писали 18 октября 2011 г., 17:20:56:
    But when we using SVN v1.7.0 (console client from the same build as
    server; or TortoiseSVN), we had a problem. When user (who is
    restricted to access /RestrictedDir) tries to make svn update on the
    root dir (/Sample), he got error as I described above.

    Updating '.'
    Restored 'Sample\AnyDir\RestrictedDir'
    svn: E155000: Failed to mark
    'D:\BUILD_ROOT\PROJECT\trunk\Sample\AnyDir\RestrictedDir'
    absent: item of the same name is already scheduled for addition

    SVN does not skip this directory, it creates is locally(!) as empty
    directory(!) and stop/fail on svn update after this.

    That's all.
    SS> Can you please clarify which versions were running on the client
    SS> and which version was running on the server when the problem
    appeared?
    SS> Both running 1.7?
    SS> Server 1.6 and clients 1.7?
    SS> Clients 1.6 and server 1.7?

    SS> From what you're saying the only thing I understand is that both
    SS> 1.6 client and 1.6 server was working.

    All for users, who have no access to restricted dir:

    1. Server: SVN v1.7.0 (WANdisco build)
    Client: TortoiseSVN v1.7.0

    NOT WORKING (update problem; empty directory created, update
    failed)
    2. Server: SVN v1.7.0 (WANdisco build)
    Client: Console SVN v1.7.0 (WANdisco build)

    NOT WORKING (update problem; empty directory created, update
    failed)
    3. Server: SVN v1.7.0 (WANdisco build)
    Client: TortoiseSVN v1.6.15 (Subversion v1.6.16)

    [!] WORKING as previous behaviour!

    So, the problem is really inside CLIENT interpretation of server
    statuses. Both new version of console svn.exe (svn client) and
    TortoiseSVN working incorrectly now.
    JC> Is it broken only for working copies that were upgraded from 1.6 to
    JC> 1.7, or also for new checkouts done with your 1.7 client?

    JC> I'm wondering if it's a bug in the upgrade code (server-excluded nodes
    JC> being incorrectly upgraded), or in the general handling of
    JC> server-exluded nodes in 1.7.

    Yes, you are right, it is a bug with upgrade procedure.

    I made an expirement:

    1. Made a clean checkout to a new place on a computer of user with
    restricted access. Checkout was without any problem.
    2. After this I tried to make svn update -- all was fine.
    3. After this from my computer I made a "cross" commit (one commit
    includes a change to a files, where users have no access, and to a
    files accessed by them).
    I used SVN update on root directory on restricted-users -- all was
    fine.

    So, if a clean checkout (without upgrade) is made, there is no such
    problem.
    Ok, with that information I reproduced this problem in the Subversion test
    suite on upgrading a working copy with server excluded (or 'absent') nodes.
    After the upgrade updates fail.

    I will look into fixing this problem tomorrow. (If somebody else wants to
    look first, please let me know ;-)

    Bert
  • Bert Huijben at Oct 18, 2011 at 10:17 pm

    -----Original Message-----
    From: Bert Huijben
    Sent: dinsdag 18 oktober 2011 19:43
    To: 'Andrey'; 'Johan Corveleyn'
    Cc: 'Stefan Sperling'; users@subversion.apache.org
    Subject: RE: Re[4]: Very big problems with access rights (authz file using) in
    SVN v1.7.0
    Ok, with that information I reproduced this problem in the Subversion test
    suite on upgrading a working copy with server excluded (or 'absent') nodes.
    After the upgrade updates fail.

    I will look into fixing this problem tomorrow. (If somebody else wants to
    look first, please let me know ;-)
    The problem is fixed on trunk and I nominated it for backport.

    Please ping your favorite committer to make him review the patch for
    inclusion in 1.7.1 ;)

    All upgrades of working copies that contains information on subdirectories
    where the user doesn't have access to, have this same problem. I think the
    only real way to resolve this issue on a working copy is checking out again.

    Bert
  • Johan Corveleyn at Oct 18, 2011 at 10:32 pm

    On Wed, Oct 19, 2011 at 12:17 AM, Bert Huijben wrote:
    -----Original Message-----
    From: Bert Huijben
    Sent: dinsdag 18 oktober 2011 19:43
    To: 'Andrey'; 'Johan Corveleyn'
    Cc: 'Stefan Sperling'; users@subversion.apache.org
    Subject: RE: Re[4]: Very big problems with access rights (authz file using) in
    SVN v1.7.0
    Ok, with that information I reproduced this problem in the Subversion test
    suite on upgrading a working copy with server excluded (or 'absent') nodes.
    After the upgrade updates fail.

    I will look into fixing this problem tomorrow. (If somebody else wants to
    look first, please let me know ;-)
    The problem is fixed on trunk and I nominated it for backport.

    Please ping your favorite committer to make him review the patch for
    inclusion in 1.7.1 ;)

    All upgrades of working copies that contains information on subdirectories
    where the user doesn't have access to, have this same problem. I think the
    only real way to resolve this issue on a working copy is checking out again.
    Would 'svn up -r0 path/to/restrictedDir' on an
    already-upgraded-but-broken-wc also be able to repair it?

    --
    Johan
  • Bert Huijben at Oct 18, 2011 at 10:45 pm

    -----Original Message-----
    From: Johan Corveleyn
    Sent: woensdag 19 oktober 2011 0:32
    To: Bert Huijben
    Cc: Andrey; Stefan Sperling; users@subversion.apache.org
    Subject: Re: Re[4]: Very big problems with access rights (authz file using) in
    SVN v1.7.0
    On Wed, Oct 19, 2011 at 12:17 AM, Bert Huijben wrote:
    -----Original Message-----
    From: Bert Huijben
    Sent: dinsdag 18 oktober 2011 19:43
    To: 'Andrey'; 'Johan Corveleyn'
    Cc: 'Stefan Sperling'; users@subversion.apache.org
    Subject: RE: Re[4]: Very big problems with access rights (authz file using) in
    SVN v1.7.0
    Ok, with that information I reproduced this problem in the Subversion
    test
    suite on upgrading a working copy with server excluded (or 'absent') nodes.
    After the upgrade updates fail.

    I will look into fixing this problem tomorrow. (If somebody else wants
    to
    look first, please let me know ;-)
    The problem is fixed on trunk and I nominated it for backport.

    Please ping your favorite committer to make him review the patch for
    inclusion in 1.7.1 ;)

    All upgrades of working copies that contains information on
    subdirectories
    where the user doesn't have access to, have this same problem. I think
    the
    only real way to resolve this issue on a working copy is checking out
    again.
    Would 'svn up -r0 path/to/restrictedDir' on an
    already-upgraded-but-broken-wc also be able to repair it?
    No, this won't work.

    This trick relies on receiving the update from the current state to r0 from
    the server, but you don't have the authorization to get this update from the
    server.

    Bert
  • Johan Corveleyn at Oct 19, 2011 at 7:26 am

    On Wed, Oct 19, 2011 at 12:45 AM, Bert Huijben wrote:
    -----Original Message-----
    From: Johan Corveleyn
    Sent: woensdag 19 oktober 2011 0:32
    To: Bert Huijben
    Cc: Andrey; Stefan Sperling; users@subversion.apache.org
    Subject: Re: Re[4]: Very big problems with access rights (authz file using) in
    SVN v1.7.0
    On Wed, Oct 19, 2011 at 12:17 AM, Bert Huijben wrote:
    -----Original Message-----
    From: Bert Huijben
    Sent: dinsdag 18 oktober 2011 19:43
    To: 'Andrey'; 'Johan Corveleyn'
    Cc: 'Stefan Sperling'; users@subversion.apache.org
    Subject: RE: Re[4]: Very big problems with access rights (authz file using) in
    SVN v1.7.0
    Ok, with that information I reproduced this problem in the Subversion
    test
    suite on upgrading a working copy with server excluded (or 'absent') nodes.
    After the upgrade updates fail.

    I will look into fixing this problem tomorrow. (If somebody else wants
    to
    look first, please let me know ;-)
    The problem is fixed on trunk and I nominated it for backport.

    Please ping your favorite committer to make him review the patch for
    inclusion in 1.7.1 ;)

    All upgrades of working copies that contains information on
    subdirectories
    where the user doesn't have access to, have this same problem. I think
    the
    only real way to resolve this issue on a working copy is checking out
    again.
    Would 'svn up -r0 path/to/restrictedDir' on an
    already-upgraded-but-broken-wc also be able to repair it?
    No, this won't work.

    This trick relies on receiving the update from the current state to r0 from
    the server, but you don't have the authorization to get this update from the
    server.
    And 'svn up -r0 path/to/parentOfRestrictedDir'?

    --
    Johan
  • Bert Huijben at Oct 19, 2011 at 9:07 am

    -----Original Message-----
    From: Johan Corveleyn
    Sent: woensdag 19 oktober 2011 9:26
    To: Bert Huijben
    Cc: Andrey; Stefan Sperling; users@subversion.apache.org
    Subject: Re: Re[4]: Very big problems with access rights (authz file using) in
    SVN v1.7.0
    On Wed, Oct 19, 2011 at 12:45 AM, Bert Huijben wrote:

    -----Original Message-----
    From: Johan Corveleyn
    Sent: woensdag 19 oktober 2011 0:32
    To: Bert Huijben
    Cc: Andrey; Stefan Sperling; users@subversion.apache.org
    Subject: Re: Re[4]: Very big problems with access rights (authz file using) in
    SVN v1.7.0
    On Wed, Oct 19, 2011 at 12:17 AM, Bert Huijben wrote:
    -----Original Message-----
    From: Bert Huijben
    Sent: dinsdag 18 oktober 2011 19:43
    To: 'Andrey'; 'Johan Corveleyn'
    Cc: 'Stefan Sperling'; users@subversion.apache.org
    Subject: RE: Re[4]: Very big problems with access rights (authz file using) in
    SVN v1.7.0
    Ok, with that information I reproduced this problem in the
    Subversion
    test
    suite on upgrading a working copy with server excluded (or 'absent') nodes.
    After the upgrade updates fail.

    I will look into fixing this problem tomorrow. (If somebody else
    wants
    to
    look first, please let me know ;-)
    The problem is fixed on trunk and I nominated it for backport.

    Please ping your favorite committer to make him review the patch for
    inclusion in 1.7.1 ;)

    All upgrades of working copies that contains information on
    subdirectories
    where the user doesn't have access to, have this same problem. I
    think
    the
    only real way to resolve this issue on a working copy is checking out
    again.
    Would 'svn up -r0 path/to/restrictedDir' on an
    already-upgraded-but-broken-wc also be able to repair it?
    No, this won't work.

    This trick relies on receiving the update from the current state to r0
    from
    the server, but you don't have the authorization to get this update from the
    server.
    And 'svn up -r0 path/to/parentOfRestrictedDir'?
    This has the same effect as a normal update op parentOfRestricted dir. So
    you probably receive a tree conflict (restricted dir is not unmodified)
    *and* the failed update (security problem).

    Bert
  • Andrey at Oct 18, 2011 at 1:45 pm
    [...]

    SS> Can you please clarify which versions were running on the client
    SS> and which version was running on the server when the problem appeared?

    SS> Both running 1.7?
    SS> Server 1.6 and clients 1.7?
    SS> Clients 1.6 and server 1.7?

    SS> From what you're saying the only thing I understand is that both
    SS> 1.6 client and 1.6 server was working.

    Forgot to write a state before update:

    4. Server: SVN v1.6.5 (CollabNet build)
    Client: TortoiseSVN v1.6.15 (Subversion v1.6.16)

    [!] WORKING

    --
    С уважением,
    Andrey mailto:andrey@online-solutions.ru

Related Discussions

Discussion Navigation
viewthread | post