#10110 closed defect (fixed)
Source browser permission problem with files created with 'svn copy'
Reported by: | Owned by: | Remy Blank | |
---|---|---|---|
Priority: | normal | Milestone: | 0.12.3 |
Component: | version control/browser | Version: | 0.12 |
Severity: | major | Keywords: | authzpolicy, authzsourcepolicy, svn copy, permissions, subversion |
Cc: | jerome.defavereau@… | Branch: | |
Release Notes: |
Fix AuthzPolicy behavior for enforcing permissions on copied or moved source directories (see also #10208). |
||
API Changes: | |||
Internal Changes: |
Description (last modified by )
Hello,
There's a bug (or I presume so) with permissions when a private directory is copied (with 'svn copy') as a new public directory. The children files inherits the permissions set from the initial directory (private) until they gets modified.
The permissions are set in the AuthzPolicy conf file. The problem appears also when setting permissions with AuthzSourcePolicy. When browsing the repository with the apache/webdav/svn sequence and the same authz file as the one used for AuthzSourcePolicy, there's no problem. So I infer it as a Trac problem and not a svn one.
Example:
State 1
Repository state before the 'svn copy':
Directory/File | Revision # | Viewable by anonymous? |
/private/ | 1 | No |
fileA | 1 | No |
State 2
Then, we
$ svn copy private public A public $ svn commit Adding public Committed revision 2.
Let's allow the 'public' dir to be viewable by everybody with the following AuthzPolicy conf file (excerpt):
[repository:*@*/source:/@*] * = BROWSER_VIEW [repository:*@*/source:public@*] * = BROWSER_VIEW [repository:*@*/source:public/*@*] * = BROWSER_VIEW, FILE_VIEW
Now, the repository looks as:
Directory/File | Revision # | Viewable by anonymous? |
/private/ | 1 | No |
fileA | 1 | No |
/public/ | 2 | Yes |
fileA | 1 | No !!! :-( |
The bug: while the 'public' folder can be browsed as an anonymous user, fileA doesn't shows up in the file list of the Trac Browser! :-(
State 3
We can add a new file in public (fileB)
$ touch public/fileB $ svn add public/fileB A public/fileB $ svn commit Adding public/fileB Transmitting file data . Committed revision 3.
Repository state after commit:
Directory/File | Revision # | Viewable by anonymous? |
/private/ | 1 | No |
fileA | 1 | No |
/public/ | 3 | Yes |
fileA | 1 | No !!! |
fileB | 3 | Yes |
fileB displays in the file list of the Trac Browser and its content can be viewed by anonymous (fileA doesn't).
State 4
Finally, modifying public/fileA renders it viewable by anonymous:
$ echo 'yoplaboum' >> public/fileA $ svn commit Sending public/fileA Transmitting file data . Committed revision 4.
Directory/File | Revision # | Viewable by anonymous? |
/private/ | 1 | No |
fileA | 1 | No |
/public/ | 4 | Yes |
fileA | 4 | Yes |
fileB | 3 | Yes |
Summary: State 2 and 3 are not correctly handled by Trac.
Note that at State ≥2 , fileA is correctly displayed when listed/viewed through apache/webdav/svn.
Attachments (0)
Change History (8)
comment:1 by , 14 years ago
Milestone: | → 0.12.3 |
---|---|
Owner: | set to |
comment:3 by , 14 years ago
Milestone: | 0.12.3 |
---|
comment:4 by , 14 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
I assume you meant to close, then.
comment:5 by , 13 years ago
Description: | modified (diff) |
---|---|
Resolution: | duplicate |
Status: | closed → reopened |
Actually the reported use case also covers the AuthzPolicy in addition to the AuthzSourcePolicy. As #9976 and #10208 only focus on the latter, let's use this ticket for mentioning the change affecting the former policy.
comment:6 by , 13 years ago
Release Notes: | modified (diff) |
---|
Verified to be fixed at [10914].
Note that the behavior added by #9976 in AuthzSourcePolicy (make visible the parent folders of accessible resources, so that the latter can be discovered) is not transposed here for the AuthzPolicy. It probably should, but that's another topic…
comment:7 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:8 by , 13 years ago
Milestone: | → 0.12.3 |
---|
- updated milestone according to cboos decision to handle the reported case as a separate issue
Very nice bug report, thank you.