Bug in authz exclusion markers

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug in authz exclusion markers

Grierson, David (Lead Engineer)
Hi,

I've just deployed Subversion v1.11.1 and have run into an issue with the use of the exclusion marker within authz files.

See the attached authz file for data for the test cases.

This file contains two groups:
  1. "user-group" is a list of users (which might be used for specific repository access later in the file); membership : namedUser
  2. "blocked-group" is a list of users who are to be blocked : membership: blockedUser

The authz file contains a rule for the top level access which declares that anyone NOT in the blocked-group should get read-write access. Users in the blocked-group should only get read-only access.

TEST CASES:
 1. What access does namedUser have?

$ svnauthz accessof svn_access_test --username namedUser
rw

Result: PASS

 2. What access does blockedUser have?

$ svnauthz accessof svn_access_test --username blockedUser
r

Result: PASS

 3. What access does unnamedUser (a user who is authenticated to access Subversion but not mentioned in the authz file) have?

$ svnauthz accessof svn_access_test --username unnamedUser
r

Result: FAIL

My interpretation of this is a bug in the authz validation - can anyone else confirm that my thinking on this is correct or am I missing something with this?

Thanks,

David.
--
David Grierson - Lead Engineer
Sky - UK Information Systems - Tools Team



Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD

svn_access_test (304 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug in authz exclusion markers

Branko Čibej
On 07.10.2019 13:49, Grierson, David (Lead Engineer) wrote:

> Hi,
>
> I've just deployed Subversion v1.11.1 and have run into an issue with the use of the exclusion marker within authz files.
>
> See the attached authz file for data for the test cases.
>
> This file contains two groups:
>   1. "user-group" is a list of users (which might be used for specific repository access later in the file); membership : namedUser
>   2. "blocked-group" is a list of users who are to be blocked : membership: blockedUser
>
> The authz file contains a rule for the top level access which declares that anyone NOT in the blocked-group should get read-write access. Users in the blocked-group should only get read-only access.
>
> TEST CASES:
>  1. What access does namedUser have?
>
> $ svnauthz accessof svn_access_test --username namedUser
> rw
>
> Result: PASS
>
>  2. What access does blockedUser have?
>
> $ svnauthz accessof svn_access_test --username blockedUser
> r
>
> Result: PASS
>
>  3. What access does unnamedUser (a user who is authenticated to access Subversion but not mentioned in the authz file) have?
>
> $ svnauthz accessof svn_access_test --username unnamedUser
> r
>
> Result: FAIL
>
> My interpretation of this is a bug in the authz validation - can anyone else confirm that my thinking on this is correct or am I missing something with this?


It's hard to say without seeing the actual authz and group definition
files. The authnz handling is interesting enough that we really need
complete information to reproduce and debug. Sometimes the correct
behaviour is not intuitive.

-- Brane

Reply | Threaded
Open this post in threaded view
|

RE: [EXTERNAL] Re: Bug in authz exclusion markers

Grierson, David (Lead Engineer)
> It's hard to say without seeing the actual authz and group definition
> files. The authnz handling is interesting enough that we really need
> complete information to reproduce and debug. Sometimes the correct
> behaviour is not intuitive.

The authz file was attached to the message sent to the group.

See attachments on the following archived message:

https://lists.apache.org/thread.html/b267384886526699530a1a4750db4aa631d9e8b5ddf56776848d84ce@%3Cusers.subversion.apache.org%3E

--
David Grierson - Lead Engineer
Sky - UK Information Systems - Tools Team




Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD