> > Hmmm... I'm sure you're right, but section 3.2.4 of the tortoise docs,
> > "Authentication with svnserve", talks about the "conf/svnserve.conf
> > file in
> > your repository directory. This file controls the configuration of the
> > svnserve daemon..."
> >
> > Am I confused?
>
> Yes, but I'm not sure about what. :-)
Well specifically, I was responding to this statement:
> > First, there's no such thing as an [auth] section in svnserve.conf.
> > You're mixing it up with a config section from the *client* side
> > ~/.subversion/servers file.
...and the tortoise docs seem to be saying that there is such a section. Is
that wrong?
If it does exist, that's on the server side, controlling svnserve, right?
> On the server side, there's a repository, and there are server
> processes (either apache or svnserve.) Access control on the
> repository is control by the server processes, as described in
> chapter 6.
Understood.
> In the case of Apache, there's an authorization 'module'
> you need to install.
I've got that working, access controlled appropriately for my purposes I
think, though that may evolve.
> In the case of svnserve, authorization is
> controlled by the 'svnserve.conf' file within the repository's conf/
> subdirectory.
Um, I hate to be a complete dork, but I'd like to shut svnserve off
completely, have it not run, but I can't see how to do that (I'm on win2k).
I don't see a windows service running it, or anything in the running
processes list that I can identify, nothing.
Where is svnserve running? Is there some reason I can't or shouldn't shut it
down, and use only apache-based access? How do I make it not run?
> On the client side, there's a client program. It makes network
> requests, and they're either allowed or disallowed by the server
> process. In addition, there's a 'client configuration' area in each
> user's home directory (~/.subversion/) which has files that control
> various run-time behaviors of the svn client. That's explained in
> chapter 6.
I'm not trying to prevent access by controlling the client side, if that's
what you mean. That seems silly; if access control is a real need, it has to
be done at the server(s), where it affects all users, and where users can't
change it.
If anything, I'd want to defeat the possibility of clients caching passwords
as a security thing. OTOH, it would be more of a pain to reenter it for
every operation. OTOOH, I don't expect people to be doing a whole ton of
repo actions in quick succession, which is where that would matter.
How do you folks handle this? Do you allow auth caching?
> What's confusing you, perhaps is the odd case of file:/// URLs. When
> a client accesses a repository directly via file:///, there's no
> network, and thus no separation between client and server. The
> client and the server are the same program. And in this case,
> there's no authentication or authorization, other than whatever the
> operating system allows. That is: either the operating system
> allows you to read/write the repository database files, or it doesn't.
Right, that is an odd discontinuity with other topologies. I really would
prefer to disable file:/// urls completely, especially from other machines.
Is it true that if other users don't have access to the file system on my
machine, they also can't access file:/// urls there?
There's no way to disable file:/// urls globally, including on the repo host
machine, right? SVN creates those inherently when there's a repository?
> You can certainly use an http:// url locally, and then set the
> operating system permissions on the repository such that local users
> aren't allowed to access the repository directly.
>
> In other words, set things up such that apache runs as a specific
> user, and then make sure that *only* the 'apache user' has OS-
> permissions to access the repository files.
Understood. Since I'm the admin of this machine, it'd be unusual for me not
to have all permissions on some files, but I understand the issue.
Thanks again for your help, and patience,
Dave Merrill
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun May 22 13:54:16 2005