subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cooke, Mark" <mark.co...@siemens.com>
Subject RE: Subversion repository config problem
Date Thu, 10 Nov 2011 08:03:11 GMT
> -----Original Message-----
> From: Tony Butt [mailto:Tony.Butt@cea.com.au] 
> Sent: 10 November 2011 07:15
> To: Cooke, Mark
> Cc: users@subversion.apache.org
> Subject: RE: Subversion repository config problem
> 
> On Thu, 2011-11-10 at 06:59 +0000, Cooke, Mark wrote:
> >
> > > The second problem is that we run trac, and (as recommended
> > > by the trac project) use post-commit hooks to log repository
> > > changes into the trac timeline. This fails when svn+ssh://
> > > is used, as the process owner does not have permission to
> > > use trac-admin in that way.
> >
> > ...as a trac user (but being a windoze shop, not svn+ssh) I 
> > was wondering, is this a fundamental trac problem or a local 
> > configuration issue?  If it is trac then it should be 
> > reported to trac-users too...
>
> Normally your svn+ssh process runs as the user who's credentials
> were supplied. Trac-admin does not allow general users to do much 
> of anything on a linux box, not sure about windows.

Forgive my *nix noob status but is that not due to the local security configuration, I do
not think that is built in to the trac code itself?  Professional versions of windoze can
be configured for security but the defaults are much more "relaxed" than *nix (AFAIK)!

> I would say it was a fundamental trac problem, resulting from a
> collision of 2 sets of assumptions for security. That is, 
> svnserve will run as a local, authenticated user for security,
> audit trail, etc.  trac-admin will only update the timeline (or
> make any other change) if it is superuser (or somesuch).

...or perhaps just the assumption that if you are using http(s) for trac you will be doing
the same with svn and from the same user.  Hmm, thinking about it, there should be no reason
for the httpd user to run trac-admin except for this, so putting the code in trac-admin was
perhaps a design mistake?

> There might be a way to configure trac-admin to allow anyone to make
> those changes, but that exposes the trac installation to greater risk.

...so one solution would be to split the update code out of trac-admin so that can be made
available without exposing the more powerful admin functionality?

I think this might be worth a ticket at t.e.o...

> Sigh - I will just strongly suggets to our engineers that they use
> http:// protocol only, most do already.
> 
> Tony
> >
> > ~ mark c
> 

Mime
View raw message