You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ken Johnson <KJ...@eclypse.org> on 2004/05/05 16:19:30 UTC

Documentation problem report, .pdf version only:

Documentation problem report, .pdf version only:

In Chapter 5, section 'Repository Cleanup', following the first Warning,
following sentence appears. 

"Another common use of svnadmin is to query the repository for
outstanding-possibly Subverdead-sion transactions."

In at least one of the HTML versions this sentence appears correctly.

(...outstanding -- possibly dead -- Subversion transactions.}

A similar problem occurs on page 83, in the paragraph beginning
"Incremental backups..."  It might be worthwhile to examine the
document sources systematically for similar constructs which are
not converting to .pdf in the desired way.

Regards,

Ken Johnson




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Documentation problem report, .pdf version only:

Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-05-05 at 11:19, Ken Johnson wrote:

> A similar problem occurs on page 83, in the paragraph beginning
> "Incremental backups..."  It might be worthwhile to examine the
> document sources systematically for similar constructs which are
> not converting to .pdf in the desired way.

The docbook-xml source is totally clean.  What you're seeing is either a
bug in the XSL sheet which creates the .FO file (when run through an
XSLT transform), or a bug in FOP, which is the java app that converts
.FO into PDF.  There's nothing we can do about these bugs.




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: newbie vs access control

Posted by Seth Falcon <sf...@fhcrc.org>.
On Wed, May 05, 2004 at 07:33:39PM +0100, Robin Becker wrote:
> but the Apache BasicUsers do or am I mistaken in that too?

I think that should work.  I haven't tried it as such, but I'm doing
something similar: Our setup has no users file perse.  Instead we
authenticate against a Windoze domain controller using modntlm, but
still use modauthz for access control (authz file contains group
definitions and policies).

+ seth



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: newbie vs access control

Posted by Robin Becker <ro...@reportlab.com>.
Seth Falcon wrote:

.......

> 
> My understanding is that:
> 
> - Authentication can be handled either by authz_svn or any Apache module
>   that can "fake" BasicAuth.
> 
> - Access control is handled by authz_svn.  Groups are defined in the
>   AuthzSVNAccessFile and BasicAuth groups do not get used.  The
>   AuthzSVNAccessFile can define default access policies.
>

but the Apache BasicUsers do or am I mistaken in that too?

> 
>>Secondly is there any way to control access within a repository using 
>>apache Location & Rewrite?
> 
> 
> No, that's what authz_svn is for.  On the surface, using Location and
> LocationMatch directives with Apache auth will appear to work, but it
> won't be secure.  The reason, IIRC, is that svn uses mangled URLs to do
> the WEBDAV stuff and those URLs won't match your Location directives.
> Otherwise, there wouldn't really be a point of the authzsvn module ;-)
> 
> + seth

I guess that's why I asked; thanks :)

-- 
Robin Becker

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: newbie vs access control

Posted by Seth Falcon <sf...@fhcrc.org>.
On Wed, May 05, 2004 at 06:49:30PM +0100, Robin Becker wrote:
> First off I don't really understand example 6.3. Is it authz_svn_module & 
> AuthzSVNAccessFile that triggers a username request? Can I also require 
> that a valid group be obtained? Are the group names from my AuthGroupFile 
> usable inside AuthzSVNAccessFile?

My understanding is that:

- Authentication can be handled either by authz_svn or any Apache module
  that can "fake" BasicAuth.

- Access control is handled by authz_svn.  Groups are defined in the
  AuthzSVNAccessFile and BasicAuth groups do not get used.  The
  AuthzSVNAccessFile can define default access policies.

> Secondly is there any way to control access within a repository using 
> apache Location & Rewrite?

No, that's what authz_svn is for.  On the surface, using Location and
LocationMatch directives with Apache auth will appear to work, but it
won't be secure.  The reason, IIRC, is that svn uses mangled URLs to do
the WEBDAV stuff and those URLs won't match your Location directives.
Otherwise, there wouldn't really be a point of the authzsvn module ;-)

+ seth




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: newbie vs access control

Posted by Robin Becker <ro...@reportlab.com>.
Scott Lawrence wrote:

> On Wed, 2004-05-05 at 14:23, Robin Becker wrote:
> 
>>Scott Lawrence wrote:
> 
> 
>>>Yes, I do all the access control in apache using http authentication. 
>>>This means that the only (write) access to the repository has to be
>>>through http - no svnserve, no file access (we actually do some
>>>read-only access on the server itself through file access, but _never_
>>>write access).  I'd be happy to post examples...
> 
> 
>>That would be great; my understanding of Rewrite is poor. I have a suspicion 
>>that RewriteBase is involved in the sort of things I might need to do.
> 
> 
> I don't use any form of rewrite (as Seth Falcon pointed out, that would
> mean understanding and being dependent on how svn does URLs internally,
> which would be bad).
> 
> Known limitations of this scheme:
> 
> 1) All write access must be via https. 
> 
>    Since we wanted to have no user accounts on the server, we actually
>    see this as an advantage.
> 
> 2) Access control is only at the repository level, not the path level.  
> 
>    We do one repository per project, and that's all the granularity 
>    we need, so that too was deemed acceptable (I think that if we decide
>    we need more that I will do it in a pre-commit hook).  We name a
>    group the same as the project, and group membership controls 
>    write access.
> 
> So here's what we do - there are two (ip-based) virtual hosts, which
> both inherit the same user/group rules from the server-wide
> configuration:
> ===================================

...... Thanks for these examples. I was actually hoping someone would 
know how to shorten a URL using Rewrite. We have say

https://xxx.yyy.com/svn/repository/trunk/subproject

I was hoping we might be able to rewrite that as

https://xxx.yyy.com/svn/subproject

ie have shortcuts for the most common usages.

-- 
Robin Becker

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: newbie vs access control

Posted by Scott Lawrence <sl...@pingtel.com>.
On Wed, 2004-05-05 at 14:23, Robin Becker wrote:
> Scott Lawrence wrote:

> > Yes, I do all the access control in apache using http authentication. 
> > This means that the only (write) access to the repository has to be
> > through http - no svnserve, no file access (we actually do some
> > read-only access on the server itself through file access, but _never_
> > write access).  I'd be happy to post examples...

> That would be great; my understanding of Rewrite is poor. I have a suspicion 
> that RewriteBase is involved in the sort of things I might need to do.

I don't use any form of rewrite (as Seth Falcon pointed out, that would
mean understanding and being dependent on how svn does URLs internally,
which would be bad).

Known limitations of this scheme:

1) All write access must be via https. 

   Since we wanted to have no user accounts on the server, we actually
   see this as an advantage.

2) Access control is only at the repository level, not the path level.  

   We do one repository per project, and that's all the granularity 
   we need, so that too was deemed acceptable (I think that if we decide
   we need more that I will do it in a pre-commit hook).  We name a
   group the same as the project, and group membership controls 
   write access.

So here's what we do - there are two (ip-based) virtual hosts, which
both inherit the same user/group rules from the server-wide
configuration:
===================================
<Directory "/">
   #
   # This sets up a common access control database for everything
   #
   AuthType         Basic
   AuthName         "SIPfoundry"
   AuthDBMType      DB
   AuthDBMUserFile  /path/to/user
   AuthDBMGroupFile /path/to/group
   #
   # This ensures that only things that are explicitly allowed
   # are accessible.
   #
   Order allow,deny
   Deny from all
</Directory>
====================================

The first virtual server is for anonymous
read-only repository access over http:
================================
################################################################
#### scm.sipfoundry.org
################################################################

<VirtualHost scm.sipfoundry.org>
   ServerName   scm.sipfoundry.org

   Include conf.d/scm.SHARED.conf

   ################################################################
   ## project-specific configurations
   ################################################################

# there is one of these per project...
Include conf.d/scm.example.ANON.conf

</VirtualHost>
================================

The second virtual server is for authenticated access via https:
======================================
################################################################
#### scm.sipfoundry.org
################################################################

<VirtualHost scm.sipfoundry.org:443>
   ServerName   scm.sipfoundry.org:443

   SSLEngine on
   SSLCertificateFile    /etc/httpd/conf/ssl.crt/scm.crt
   SSLCertificateKeyFile /etc/httpd/conf/ssl.key/scm.key

   Include conf.d/scm.SHARED.conf

################################################################
## project-specific configurations
################################################################

Include conf.d/scm.example.USER.conf

</VirtualHost>
========================================

note that they both include the same general rules from scm.SHARED.conf:
========================================
### Included into scm.{ANON,USER}.conf
###
### This configures all the scm content that is not project-specific
###

# [... a couple of non-subversion things...]

   <Location /rep>
     DAV svn
     # any "/rep/foo" URL will map to a repository /scm/rep/foo
     SVNParentPath /scm/rep
     Allow from all

     # For any operations other than these, 
     # require an authenticated user.
     <LimitExcept GET PROPFIND OPTIONS REPORT>
       Satisfy All
       Allow from all
       Require valid-user
     </LimitExcept>
   </Location>

=========================================

then each project gets a pair of include files that get inserted into
the ANON and USER virtual host rules respectively:

The one for anonymous project read access (included above as
scm.example.ANON.conf):
==========================================

################################################################
## Project example
################################################################


<Location /rep/example/>
  <LimitExcept GET PROPFIND OPTIONS REPORT>
    Deny from all
  </LimitExcept>

</Location>
===========================================

and the one that permits authenticated write access (included above as
scm.example.USER.conf):
===========================================

################################################################
## Project example
################################################################

<Location /rep/example/>
  <LimitExcept GET PROPFIND OPTIONS REPORT>
    Satisfy all
    SSLRequireSSL
    Require group example
  </LimitExcept>
</Location>

===========================================

-- 
  Scott Lawrence
  SIPfoundry.org system administrator
  postmaster@sipfoundry.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: newbie vs access control

Posted by Robin Becker <ro...@reportlab.com>.
Scott Lawrence wrote:
> On Wed, 2004-05-05 at 13:49, Robin Becker wrote:
> 
......
> My understanding is that those are two different things -
> authz_svn_module & AuthzSVNAccessFile are access control _inside_ svn
> itself.
>

The example seems to imply something else eg
"In this setup, all users start out accessing the repository anonymously. If 
your access control policy demands a real username at any point,Apache will 
demand authentication from the client. To do this, you use both the Satisfy Any 
and Require valid-user directives together."

<Location /repos>
	DAV svn
	SVNParentPath /usr/local/svn
	# our access control policy
	AuthzSVNAccessFile /path/to/access/file
	# try anonymous access first, resort to real
	# authentication if necessary.
	Satisfy Any
	Require valid-user
	# how to authenticate a user
	AuthType Basic
	AuthName "Subversion repository"
	AuthUserFile /path/to/users/file
</Location>

My understanding was that Require valid-user is skipped initially and then 
mod_dav_svn eventually needs a user name presumably because of the 
AuthzSVNAccessFile specification. Then a valid user is requested. I'll have to 
exeperiment to test if that's not the case.

> AuthGroupFile is implemented in mod_access in Apache.
> 
> 
>>Secondly is there any way to control access within a repository using apache 
>>Location & Rewrite?
> 
> 
> Yes, I do all the access control in apache using http authentication. 
> This means that the only (write) access to the repository has to be
> through http - no svnserve, no file access (we actually do some
> read-only access on the server itself through file access, but _never_
> write access).  I'd be happy to post examples...
> 

That would be great; my understanding of Rewrite is poor. I have a suspicion 
that RewriteBase is involved in the sort of things I might need to do.

-- 
Robin Becker

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: newbie vs access control

Posted by Scott Lawrence <sl...@pingtel.com>.
On Wed, 2004-05-05 at 13:49, Robin Becker wrote:
> We're experimenting with moving our CVS repository to svn. That seems to go well 
> after I hacked the script to look at the cvs -kb flag.
> 
> I have a couple of questions related to access control.
> 
> First off I don't really understand example 6.3. Is it authz_svn_module & 
> AuthzSVNAccessFile that triggers a username request? Can I also require that a 
> valid group be obtained? Are the group names from my AuthGroupFile usable inside 
> AuthzSVNAccessFile?

My understanding is that those are two different things -
authz_svn_module & AuthzSVNAccessFile are access control _inside_ svn
itself.

AuthGroupFile is implemented in mod_access in Apache.

> Secondly is there any way to control access within a repository using apache 
> Location & Rewrite?

Yes, I do all the access control in apache using http authentication. 
This means that the only (write) access to the repository has to be
through http - no svnserve, no file access (we actually do some
read-only access on the server itself through file access, but _never_
write access).  I'd be happy to post examples...

-- 
Scott Lawrence        
  Pingtel Corp.   
  sip:slawrence {at} pingtel.com  
  +1.781.938.5306 x162



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

newbie vs access control

Posted by Robin Becker <ro...@reportlab.com>.
We're experimenting with moving our CVS repository to svn. That seems to go well 
after I hacked the script to look at the cvs -kb flag.

I have a couple of questions related to access control.

First off I don't really understand example 6.3. Is it authz_svn_module & 
AuthzSVNAccessFile that triggers a username request? Can I also require that a 
valid group be obtained? Are the group names from my AuthGroupFile usable inside 
AuthzSVNAccessFile?

Secondly is there any way to control access within a repository using apache 
Location & Rewrite?

Is there any way to decide if the repository should be open by default or closed?
-- 
Robin Becker

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Documentation problem report, .pdf version only:

Posted by Jan Normann Nielsen <li...@dubbekarl.dk>.
Ken Johnson wrote:

>Documentation problem report, .pdf version only:
>
>In Chapter 5, section 'Repository Cleanup', following the first Warning,
>following sentence appears. 
>
>"Another common use of svnadmin is to query the repository for
>outstanding-possibly Subverdead-sion transactions."
>
>In at least one of the HTML versions this sentence appears correctly.
>
>(...outstanding -- possibly dead -- Subversion transactions.}
>
>A similar problem occurs on page 83, in the paragraph beginning
>"Incremental backups..."  It might be worthwhile to examine the
>document sources systematically for similar constructs which are
>not converting to .pdf in the desired way.
>  
>
I haven't read the book lately but in older releases there were a lot of 
these bugs where hyphen-broken lines moved the previous word to the end 
of the line like the one you found.

Best regards,
Jan Nielsen

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org