#5097 closed defect (fixed)
authz gives "Permission Denied" when viewing empty changeset
Reported by: | Owned by: | Remy Blank | |
---|---|---|---|
Priority: | normal | Milestone: | 0.12-multirepos |
Component: | version control | Version: | 0.10.3 |
Severity: | normal | Keywords: | svnauthz, authzsourcepolicy |
Cc: | osimons | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
If authz is enabled, trying to view an empty changeset will result in a "Permission Denied" error. Discovered in 0.10.3; inspection suggests the same bug currently exists in the trunk.
Suggested fix, in versioncontrol/svn_authz.py (there's probably a prettier way to do this):
def has_permission_for_changeset(self, rev): + seen_change = 0 changeset = self.repos.get_changeset(rev) for path,_,_,_,_ in changeset.get_changes(): + seen_change = 1 if self.has_permission(path): return 1 + if seen_change == 0: + return 1 return 0
Attachments (0)
Change History (11)
follow-up: 2 comment:1 by , 17 years ago
Version: | devel → 0.10.3 |
---|
comment:2 by , 17 years ago
Replying to sid:
In the path you have,
1
will always be the returned value. That doesn't seem quite right…
Hm, so it will. I wasn't expecting get_changes() to weed out unauthorized paths. In that case, I retract my quick fix.
comment:3 by , 17 years ago
I'm pretty sure there's already a ticket for this, but I can't find it. Also, I'm pretty sure this has been fixed, but I'm not positive.
comment:4 by , 17 years ago
Keywords: | svn_authz verify added |
---|---|
Milestone: | → 0.12 |
comment:5 by , 16 years ago
Cc: | added |
---|---|
Keywords: | verify removed |
I see this one too - I've got a repos with an empty changeset, and permissions stop me from viewing it (not much to see, but still…). Repos is not scoped, it has authz but I of course have permissions. Disable the authz file setting and it displays. I've tried to rewind my 0.11 stable some 1000 revisions back, and nothing changes - I suspect this problem is not new.
My changeset is many years old, and I have problems recreating an 'empty' changeset now. How do they arise? I have a feeling it was old Subversion (like 1.2.3 at the time) and perhaps just a property change on root or something (like an svn:ignore
perhaps), or something similar that at the time left no permanent mark in the revision log. Anyone know?
The empty changeset caused another problem following [8184], so more added to #5640.
comment:6 by , 16 years ago
In my case, large numbers of empty revisions were created when I split a repository in two with an 'svnadmin dump | filter | svnadmin load' pipeline. I think the tool did it automatically (or maybe I asked with a flag), but I also wanted the revision numbers to line up to avoid having to play stupid games with revision references in externals.
Also, according to http://subversion.tigris.org/svn_1.6_releasenotes.html ("Detection of tree conflicts" section), svn versions before 1.6 will commit an empty revision if asked to commit delete a file that has already been deleted. So you don't need crazy admin tricks, just bad luck.
comment:7 by , 16 years ago
Milestone: | 0.13 → 0.11.5 |
---|---|
Owner: | changed from | to
I'll try to solve this together with #5640.
comment:8 by , 15 years ago
Keywords: | svnauthz added; svn_authz removed |
---|---|
Milestone: | 0.11.6 → 0.12.1 |
comment:10 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
This should be fixed with [9082], where the AuthzSourcePolicy
grants permission to empty changesets as well as non-empty changesets where access is granted to at least one modified file.
comment:11 by , 11 years ago
Keywords: | authzsourcepolicy added |
---|
In the path you have,
1
will always be the returned value. That doesn't seem quite right…