Hello again,
I thought I'd provide an update in case it might spark an idea in someone.
I've managed to get the old repo locations to behave the same as the new
parent path one, in that it just 403s when the userRO tries to GET the root
of the repository he does have some subfolder access. Not ideal, but at
least consistent. I've discovered if I give userRO 'r' access in [svn2:/],
and then '' access in every single folder I don't want him to have access
to, it behaves the way I'd like: GET /repos/svn2/ (or /svn/svn2/) shows
only the AllowedPathA and AllowedPathB. Incredibly cumbersome that I have
to manually name and deny for each other path, but I suppose that's WAI? I
spent the evening reading through some of the mod_authz_svn and
libsvn_repos/authz code, and that seems to be the way it's intended, best I
can tell, and the fact that I ever got it to behave without doing it this
way was more of a fluke than anything.
Thanks for any help and feedback,
Cheers,
Chris
On Mon, Mar 30, 2020 at 5:27 PM Chris Dailey wrote:
> Hello all,
>
> I'm attempting to move a set of repositories over to using SVNParentPath
> for some much needed organization. Currently with our setup, we've got a
> separate , each with it's own SVNPath, basic auth, and
> AuthzSVNAccessFile, and everything works like I'd expect. However, moving
> to a single , using SVNParentPath, users with limited permissions
> get different responses to the same requests.
>
> I apologize for being verbose, but I'm trying to be thorough and believe
> I've checked each spot I might have gone wrong.
>
> My old svn locations are /svn/svn1oldname/, /svn/svn2/. I'm moving them to
> /repos/(svn1|svn2)/
>
> Currently, the setup looks like this:
>
> DAV svn
> SVNPath /home/user/repos/svn1
> SVNReposName svn1oldname
> AuthzSVNAccessFile /home/user/repos/authz
> # basic auth omitted for brevity
>
>
> DAV svn
> SVNPath /home/user/repos/svn2
> # no SVNReposName, name isn't changing.
> AuthzSVNAccessFile /home/user/repos/authz
> # basic auth omitted for brevity
>
>
> The setup I'm attempting to move to (and actually have going side-by-side
> at the moment, though removing the others help,) is:
>
>
> DAV svn
> SVNParentPath /home/user/repos
> SVNListParentPath On
> # basic auth omitted for brevity
> AuthzSVNAccessFile /home/eaiuser/repos/authz
>
>
> Both repos are sharing the same AuthUserFile and AuthzSVNAccessFile. authz
> looks as such:
>
> [groups]
> admin = userS
> one = userA, userB
> two = userA, userB, userC
> two-readonly = userRO
>
> [/]
> $anonymous =
> @admin = rw
>
> [svn1:/]
> @one = rw
>
> [svn1oldname:/]
> @one= rw
>
> [svn2:/]
> @two = rw
> @two-readonly =
>
> [svn2:/AllowedPathA]
> @two-readonly = r
>
> [svn2:/AllowedPathB]
> @firmware-readonly = r
>
> Now, the behavior.
>
> userS: Can GET all urls as you'd expect.
> userA: Can GET /svn/svn1oldname/, /svn/svn2/, /repos/ (sees both
> repositories in the list), /repos/svn1/, /repos/svn2/, as expected.
> Effectively the same as userS, but only listed in @one and @two.
>
> userRO is where things get funny.
>
> userRO: Can GET /svn/svn1oldname/ but sees only the repo name and revision
> userRO: Can GET /svn/svn2/ and sees repo name, revision, AllowedPathA, and
> AllowedPathB. This is the behavior I expect.
> userRO: Can GET /repos/ (the 'collection list), but sees *no* repositories.
> userRO: Attempting to GET /repos/svn1/ gets a 403 response. Not the same
> behavior as on /svn/svn1oldname/, but completely acceptable (and honestly
> would be preferred, I think.)
> userRO: Attempting to GET /repos/svn2/ ... also gets a 403 response. This
> was unexpected to me, based on how /svn/svn2/ behaved.
> userRO: Attempting to GET /repos/svn2/AllowedPathA/ Works. Responds as
> expected, so the permission *does* seem to be getting applied properly, but
> the visibility of higher requests isn't working in the same way, so unless
> I actually tell userRO to act individually on each of the allowed paths,
> they'll never know what they have access too through this manner.
>
> I have confirmed this is the behavior using subversion 1.9.7. As that was
> the latest available from my distro's repo, I had to build 1.13.0 myself,
> and the behavior is the same across the versions. I haven't yet tried on
> the 1.14.x branch, as I don't see any notes about behavior such as this.
>
> Thanks everyone.
>
> Cheers,
>
> Chris
>
