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 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: > > > > 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 > > > > > > /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
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 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: > >> >> >> 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 >> >> >> >> > > /var/www/svn/access >> [/project/!svn] >> * = r >> >> [/project/trunk/project-web] >> @project-web-developer = rw > > Cheers, Brian >
Re: Question about excessive mergeinfo
On Jan 9, 2010, at 7:58 AM, Geoff Rowell wrote: > I follow a few rules to avoid this: > 1) Remove obsolete merge info as part of the branch creation process > (svn pd -R svn:mergeinfo /my/branch). I don't do that regularly (but have done it once or twice), but from my understanding, that fixes the "problem"/annoyance where existing subtree mergeinfo gets updated every time a merge is done, even if the merge doesn't affect the files with mergeinfo. That's not the same issue as what I'm seeing though; in my case, mergeinfo is being created on files that didn't have it before. > 2) Only allow recording of merge info at the root level. This means > that all merges must take place to and from the root of branches and > the trunk. (In fact, a pre-commit hook prevents saving merge info > anywhere else.) I do always merge at the root. > 3) Remove merge info from trunk when a branch is no longer under > active development. This also seems to address the issue of updates on existing mergeinfo, but not creation of new mergeinfo.
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 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 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: >> >> >> >> 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 >> >> >> >> >> >> /var/www/svn/access >> >> [/project/!svn] >> * = r >> >> [/project/trunk/project-web] >> @project-web-developer = rw >> >> >> Cheers, Brian >> > > >
Re: Question about excessive mergeinfo
On 1/9/2010 11:36 AM, David Huang wrote: On Jan 9, 2010, at 7:58 AM, Geoff Rowell wrote: I follow a few rules to avoid this: 1) Remove obsolete merge info as part of the branch creation process (svn pd -R svn:mergeinfo /my/branch). I don't do that regularly (but have done it once or twice), but from my understanding, that fixes the "problem"/annoyance where existing subtree mergeinfo gets updated every time a merge is done, even if the merge doesn't affect the files with mergeinfo. That's not the same issue as what I'm seeing though; in my case, mergeinfo is being created on files that didn't have it before. FWIW, I made a backup of my repo, then in the backup, removed all mergeinfo from trunk and made a new branch off of trunk. I confirmed that the branch also has no mergeinfo. I then made a commit to the trunk and merged that commit to the branch. It caused the same problem where mergeinfo was added to every file in those 4 directories that have externals. As a second test, I removed all the external definitions from trunk, made yet another branch off of trunk, committed a change to trunk, then merged the change to the branch. Mergeinfo was created on the root of the branch, but nowhere else--which is what I wanted and expected. So, it seems to have something to do with the externals, but I don't know what.
Re: Problem implementing path-based authorization with authz
On Jan 9, 2010, at 12:58 PM, Rob van Oostrum wrote: > 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 > Thanks Rob. The last note does help and that seems to be correct based on my experimentation, but it seems to go a little further, that a user must have the same access to the root directory as they do for the particular directory that they are working on. So that would mean if a user in @public has rw access to and wants to commit to /project/public_files, they have to have write access to /project so the metadata can be updated. For the benefit of others that may come across this in the archives, it turns out about the only way I was able to figure out to set this up was the following: > [/project] > * = rw > > [/project/trunk/core] > @project-core-developer = rw > @project-web-developer = > > [/project/trunk/web] > @project-core-developer = > @project-web-developer = rw > > [/project/trunk/common] > @project-core-developer = rw > @project-web-developer = rw In other words, to do an exhaustive matrix of every combination of paths and access for every group for each path. Granted, some or much of this information may be irrelevant outside the Crowd environment, but the situation is worse with the stock LDAP adapters for Apache. The can't even read groups in. Anyway, thanks for thinking this through with me. Cheers, Brian
Create links between repositories ?
Hello, I'm a user of SVN and I want to know if it is possible to create links between repositories ? For exemple, if the directory /project1/trunk/includes/lib1 of repository #1 can refer to directory /lib1/trunk of repository #2 ? [file:///svn/repository-1/projet1/trunk/includes/lib1 -> file:///svn/repository-2/lib1/trunk] Is it possible? Regards, Samuel ROZE.
Re: Create links between repositories ?
You can do that within a single repository, but not between repositories. On Jan 9, 2010, at 6:23 PM, Samuel ROZE wrote: > Hello, > > I'm a user of SVN and I want to know if it is possible to create links > between repositories ? > > For exemple, if the directory /project1/trunk/includes/lib1 of > repository #1 can refer to directory /lib1/trunk of repository #2 ? > > [file:///svn/repository-1/projet1/trunk/includes/lib1 -> > file:///svn/repository-2/lib1/trunk] > > Is it possible? > > Regards, > Samuel ROZE. > >
Re: Create links between repositories ?
Sure you can. This is what the svn:externals feature is designed for. Look up the explanation in the book. http://svnbook.org Sent from my iPhone On Jan 9, 2010, at 6:30 PM, Brian Topping wrote: You can do that within a single repository, but not between repositories. On Jan 9, 2010, at 6:23 PM, Samuel ROZE wrote: Hello, I'm a user of SVN and I want to know if it is possible to create links between repositories ? For exemple, if the directory /project1/trunk/includes/lib1 of repository #1 can refer to directory /lib1/trunk of repository #2 ? [file:///svn/repository-1/projet1/trunk/includes/lib1 -> file:///svn/repository-2/lib1/trunk] Is it possible? Regards, Samuel ROZE.
