Make SVN Authz compatible with SVN 1.5

[alvaro.iradier@…]

SVN 1.5 adds $authenticated and $anonymous tokens to the svn auth file. This should be reflected on the RealSubversionAuthorizer class in svn_authz.py.

I'm attaching a suggested patch.

I think this should be applied in trac 0.11.5, no need to wait for 0.12.

[alvaro.iradier@…]

Patch to svn_auth.py to understand new svn 1.5 tokens $anonymous and $authenticated

[Christian Boos]

Please use unified diff format (diff -u), see TracDev/SubmittingPatches.

[ebray]

Note also that there's been a ticket #4997 for a while now to just use SVN's authz bindings. The argument against it at the time was that the relevant functions were not available prior to SVN 1.3. Is that really still an issue? Maybe for newer SVN versions Trac could use the available bindings—that's what I've been doing for years, rather than reimplement every new authz feature added to Subversion.

[Remy Blank]

Then there's also comment:19:ticket:5640, where we were discussing if now would be the right time to drop the authz system altogether in favor of fine-grained permissions.

[ebray]

Replying to rblank:

Then there's also comment:19:ticket:5640, where we were discussing if now would be the right time to drop the authz system altogether in favor of fine-grained permissions.

I don't understand. You still need an authz file for the SVN repository. I'd rather Trac just take repository permissions from that.

[Christian Boos]

Replying to ebray:

Replying to rblank:

Then there's also comment:19:ticket:5640, where we were discussing if now would be the right time to drop the authz system altogether in favor of fine-grained permissions.

I don't understand. You still need an authz file for the SVN repository. I'd rather Trac just take repository permissions from that.

To clarify: the authz file from Subversion would still be used to perform the same checks (minus the bugs if possible ;-) ), but for doing so we would use a new permission policy (e.g. SvnAuthzPolicy) which would apply the checks at a higher level rather than directly within the svn_fs layer.

The advantages of this are clear:

• only one system for TracFineGrainedPermissions
• possibility to re-use the SvnAuthzPolicy for other vcs than just svn
• possibility to write other dedicated policies
• it should also be possible to use the authz_policy.py​ plugin or any other generic permission policy for enforcing permissions in the source browser

[Remy Blank]

Replying to cboos:

• possibility to re-use the SvnAuthzPolicy for other vcs than just svn

This may be a reason not to use the authz parser from Subversion, to avoid a dependency on the SVN bindings when SVN is not used. OTOH, if the same effect can be achieved with authz_policy.py, I'd be in favor of #4997.

[Christian Boos]

#4997 could be optional - full support and compatibility with Subversion, at the cost of the dependency on the bindings (this also solves the backward compat issue, in case this is still a problem). It might be interesting to do some benchmarking as well and see which from the python implementation and the bindings one is most effective.

[ebray]

Replying to cboos:

To clarify: the authz file from Subversion would still be used to perform the same checks (minus the bugs if possible ;-) ), but for doing so we would use a new permission policy (e.g. SvnAuthzPolicy) which would apply the checks at a higher level rather than directly within the svn_fs layer.

I see now. In that case I'm all for it, since we long since did something similar: Added SVN_READ and SVN_WRITE permissions to our permission system, and are just kept in sync with the SVN authz file.

As for #4997, making it optional would definitely make sense in this context.

[alvaro.iradier@…]

Patch to svn_auth.py to understand new svn 1.3 tokens $anonymous and $authenticated (same as previous, in uniffied diff)

[alvaro.iradier@…]

I've attached same patch in uniffied, sorry.

Also check attached patch in 4997 as alternative.

[alvaro.iradier@…]

I found another problem with current authz file parsing that is fixed when using the svn bindings:

Windows is not case-sensitive, so permissions are applied to, for example, [/secure] even if the directory is named /Secure (uppercase S).

However, this won't work on trac, so if there exist case differences between the authz file specifications and the filesystem, permissions won't be applied. This is correct for linux/unix, but not for windows.

Using SWIG bindings like the attached patch fixes the problem.

[Christian Boos]

Replying to alvaro.iradier@…:

However, this won't work on trac, so if there exist case differences between the authz file specifications and the filesystem, permissions won't be applied. This is correct for linux/unix, but not for windows.

Using SWIG bindings like the attached patch fixes the problem.

I'd rather see that as a bug in the bindings, as the case sensitiveness of the filesystem of the OS where Trac runs is irrelevant to the way the repository is presented.

To convince yourself of that, just try the following (on Windows):

C:\Temp>svnadmin create testrep
C:\Temp>mkdir test
C:\Temp>cd test
C:\Temp\test>mkdir A
C:\Temp\test>svn import file:///C:/Temp/testrep -m "Add A"
Adding         A

Committed revision 1.

C:\Temp\test>rmdir A
C:\Temp\test>mkdir a
C:\Temp\test>svn import file:///C:/Temp/testrep -m "Add a"
Adding         a

Committed revision 2.

C:\Temp\test>svn ls file:///C:/Temp/testrep
A/
a/

So even on Windows, you can create and manipulate repositories containing mixed cases entries. The only thing you can't do obviously is to checkout the directory containing those conflicting entries, but nothing prevents you from checking them out separately.

Back to the topic, I don't think it's legitimate to consider that the [/secure] entry also applies to [/Secure], even if the repository happens to be hosted on a Windows machine.

[Remy Blank]

I'll do this.

[Remy Blank]

#4997 was closed as a duplicate.

[Remy Blank]

#9542 has a patch that adds the $anonymous and $authenticated tokens.

[Remy Blank]

It looks like SVN also supports "negation rules", by prefixing a key with ~.

Does anybody know where this is documented? I couldn't find anything except the ​changeset that adds the feature.

[Remy Blank]

Replying to rblank:

Does anybody know where this is documented?

Oh, great, the only place this seems to be documented is in the sample conf/authz file of a newly-created repository:

### As shown below each section defines authorizations for the path and
### (optional) repository specified by the section name.
### The authorizations follow. An authorization line can refer to:
###  - a single user,
###  - a group of users defined in a special [groups] section,
###  - an alias defined in a special [aliases] section,
###  - all authenticated users, using the '$authenticated' token,
###  - only anonymous users, using the '$anonymous' token,
###  - anyone, using the '*' wildcard.
###
### A match can be inverted by prefixing the rule with '~'. Rules can
### grant read ('r') access, read-write ('rw') access, or no access
### ('').

[Remy Blank]

$anonymous and $authenticated tokens implemented in [10006].

[Remy Blank]

FWIW, the negation rules seem tricky to implement, so I'm waiting for a concrete request for the functionality before implementing it. Yes, I'm lazy.