Re: problem with path based authorization
Volker Cordes wrote on Fri, Jan 13, 2017 at 18:47:17 +0100:
> Am 13.01.2017 um 15:47 schrieb Daniel Shahaf:
> > Volker Cordes wrote on Fri, Jan 13, 2017 at 10:51:19 +0100:
> >> Hello,
> >>
> >> I have set up path based authorization on a repository. If I check out
> >> the project, everything works as expected. My problem however is, that
> >> if I change permissions of a file / path and then update the working
> >> copy the files I should have no longer access to are still there. Is
> >> there a way of updating the working copy so that permissions are
> >> rechecked?
> > 'Update' does recheck permissions (that's done server-side and cannot be
> > opted out of). There ought to be some other difference. Maybe the
> > authz'd files have local mods so they weren't deleted from the tree
> > ('svn st' will show '?'). Maybe the two working copies (old and new)
> > don't use the same username or don't come from the same URL.
>
> that's it than. I'm changing the username during the update with "svn up
> --username=...". Is there any way to recheck permissions in that case?
"Permission checks" cannot be bypassed or disabled by the client.
However, I overlooked a detail earlier. While 'svn up' will remove
a file that had been made authz-unreadable, that will only happen after
the next change to the file. Until the next time the file is modified,
a working copy that has the file will retain it.
You can force the file to be discarded with
svn up -r0 file
svn cleanup
and then a following 'svn up' won't restore it. (The 'cleanup' is only
to remove the file from the pristine store.)
Cheers,
Daniel
Re: problem with path based authorization
Am 13.01.2017 um 15:47 schrieb Daniel Shahaf:
> Volker Cordes wrote on Fri, Jan 13, 2017 at 10:51:19 +0100:
>> Hello,
>>
>> I have set up path based authorization on a repository. If I check out
>> the project, everything works as expected. My problem however is, that
>> if I change permissions of a file / path and then update the working
>> copy the files I should have no longer access to are still there. Is
>> there a way of updating the working copy so that permissions are
>> rechecked?
> 'Update' does recheck permissions (that's done server-side and cannot be
> opted out of). There ought to be some other difference. Maybe the
> authz'd files have local mods so they weren't deleted from the tree
> ('svn st' will show '?'). Maybe the two working copies (old and new)
> don't use the same username or don't come from the same URL.
Hello,
that's it than. I'm changing the username during the update with "svn up
--username=...". Is there any way to recheck permissions in that case?
Thanks,
Volker
--
Tel: +49 (0) 4489 408753
Fax: +49 (0) 4489 405735
mailto: v...@fdatek.de
freeline Datentechnik GmbH & Co.KG
Wiekesch 1
26689 Apen
www.freeline-edv.de
Amtsgericht Oldenburg HRA 203347
persönlich haft. Gesellschafterin: freeline Holding GmbH, Amtsgericht Oldenburg
HRB 206967
Geschäftsführer: Volker und Tobias Cordes
Re: problem with path based authorization
Volker Cordes wrote on Fri, Jan 13, 2017 at 10:51:19 +0100:
> Hello,
>
> I have set up path based authorization on a repository. If I check out
> the project, everything works as expected. My problem however is, that
> if I change permissions of a file / path and then update the working
> copy the files I should have no longer access to are still there. Is
> there a way of updating the working copy so that permissions are
> rechecked?
'Update' does recheck permissions (that's done server-side and cannot be
opted out of). There ought to be some other difference. Maybe the
authz'd files have local mods so they weren't deleted from the tree
('svn st' will show '?'). Maybe the two working copies (old and new)
don't use the same username or don't come from the same URL.
> Or is the only possibility to check out the whole project
> again (I'd like to avoid that because of the size)?
>
> Thanks,
> Volker
>
Re: Problem implementing path-based authorization with authz
Your problem is with Crowd, not authz. Authentication is failing: Could not authenticate to server: rejected Basic challenge (https://dev.host.net) Check your Crowd configuration/documentation. I'd suggest taking SVN out of the equation and verifying that your integration with Crowd is working first. Cheers, Rob On Sat, Jan 9, 2010 at 1:19 AM, Brian Topping topp...@codehaus.org wrote: Hello all, I've been wrestling with getting authz setup in a way that must be somewhat unconventional all week and was hoping someone here on the list might be able to offer some insight. The environment is Apache httpd 2.2.3, mod_dav_svn 1.6.6, and Subversion 1.6.6. My configs follow. So far, most of the docs that I've seen on authz start by granting read access to everyone at the root of the tree, then subtracting authorizations to specific sensitive directories. My concern with this is that this allows people to lazily create directories without considering that they might be granting access to any valid user. Instead, I would like to configure path-based access to deny access to all non-root directories, then rely on specific grants to individual directories based on group. I have groups working fine, but as soon as I lock down the root directory, my svn client gets the following problem: Username: svn: PROPFIND of '/repos/project/!svn/vcc/default': authorization failed: Could not authenticate to server: rejected Basic challenge ( https://dev.host.net) I understand about the metadata located at !svn. So I added: [/project/!svn] * = r But this doesn't seem to do anything. I still get the first error. Is there a way to do what I am trying to do? I have exhaustively tested that the AuthHandler is doing asking the right questions of the authentication broker and is able to recover the correct user and group mappings. Note that I am using Atlassian's Crowd-based auth. This is a fork of standard authz to patch Crowd users and groups in, but it would be easy for me to convert to direct LDAP if necessary. /etc/httpd/conf.d/subversion.conf: Location /repos LoadModule perl_module modules/mod_perl.so LoadModule dav_svn_module modules/mod_dav_svn.so # Uncomment this to enable the repository DAV svn # Set this to the path to your repository SVNParentPath /var/www/svn/ SSLRequireSSL AuthName crowd AuthType Basic PerlAuthenHandler Apache::CrowdAuth PerlSetVar CrowdAppName subversion PerlSetVar CrowdAppPassword xxx PerlSetVar CrowdSOAPURL https://dev.host.net/crowd/services/SecurityServer PerlAuthzHandler Apache::CrowdAuthz PerlSetVar CrowdAuthzSVNAccessFile /var/www/svn/access require valid-user /Location /var/www/svn/access [/project/!svn] * = r [/project/trunk/project-web] @project-web-developer = rw Cheers, Brian
Re: Problem implementing path-based authorization with authz
I see now. The path /project/!svn makes no sense. It doesn't exist in the repository, so that rule doesn't do anything. The !svn is a SVN-internal concept. To assign permissions to /project, you need to have to specify: [/project] * = r Do a search on the old list archives on tigris for some background. If I remember correctly, you cannot have less than global read permissions on the repository's root if you're on SVN 1.5 or later. Hope this helps, Rob On Sat, Jan 9, 2010 at 12:09 PM, Brian Topping topp...@codehaus.org wrote: Thanks, but that is incorrect. I have no problem downloading sources with a single rule of [/project] *=r, nor do I have a problem correctly resolving group memberships that a user has assigned to them. As well, I have tested that a user who is not logged in cannot access the repository. Arguably, this is a problem with Apache HTTPD, not SVN. I posted here because I thought that it was more likely that someone here had approached this problem and solved it. My apologies in advance if anyone takes issue with that. Cheers, Brian On Jan 9, 2010, at 11:58 AM, Rob van Oostrum wrote: Your problem is with Crowd, not authz. Authentication is failing: Could not authenticate to server: rejected Basic challenge (https://dev.host.net ) Check your Crowd configuration/documentation. I'd suggest taking SVN out of the equation and verifying that your integration with Crowd is working first. Cheers, Rob On Sat, Jan 9, 2010 at 1:19 AM, Brian Topping topp...@codehaus.orgwrote: Hello all, I've been wrestling with getting authz setup in a way that must be somewhat unconventional all week and was hoping someone here on the list might be able to offer some insight. The environment is Apache httpd 2.2.3, mod_dav_svn 1.6.6, and Subversion 1.6.6. My configs follow. So far, most of the docs that I've seen on authz start by granting read access to everyone at the root of the tree, then subtracting authorizations to specific sensitive directories. My concern with this is that this allows people to lazily create directories without considering that they might be granting access to any valid user. Instead, I would like to configure path-based access to deny access to all non-root directories, then rely on specific grants to individual directories based on group. I have groups working fine, but as soon as I lock down the root directory, my svn client gets the following problem: Username: svn: PROPFIND of '/repos/project/!svn/vcc/default': authorization failed: Could not authenticate to server: rejected Basic challenge (https://dev.host.net) I understand about the metadata located at !svn. So I added: [/project/!svn] * = r But this doesn't seem to do anything. I still get the first error. Is there a way to do what I am trying to do? I have exhaustively tested that the AuthHandler is doing asking the right questions of the authentication broker and is able to recover the correct user and group mappings. Note that I am using Atlassian's Crowd-based auth. This is a fork of standard authz to patch Crowd users and groups in, but it would be easy for me to convert to direct LDAP if necessary. /etc/httpd/conf.d/subversion.conf: Location /repos LoadModule perl_module modules/mod_perl.so LoadModule dav_svn_module modules/mod_dav_svn.so # Uncomment this to enable the repository DAV svn # Set this to the path to your repository SVNParentPath /var/www/svn/ SSLRequireSSL AuthName crowd AuthType Basic PerlAuthenHandler Apache::CrowdAuth PerlSetVar CrowdAppName subversion PerlSetVar CrowdAppPassword xxx PerlSetVar CrowdSOAPURL https://dev.host.net/crowd/services/SecurityServer PerlAuthzHandler Apache::CrowdAuthz PerlSetVar CrowdAuthzSVNAccessFile /var/www/svn/access require valid-user /Location /var/www/svn/access [/project/!svn] * = r [/project/trunk/project-web] @project-web-developer = rw Cheers, Brian
