On May 22, 2005, at 6:52 AM, Dave Merrill wrote:
>
>>> 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?
>
I don't know anything about the tortoisesvn docs. If they say that,
then yes, it's wrong. repos/conf/svnserve.conf has exactly one
section, called [general]. If you see an error in the tortoise docs,
point it out on the tortoisesvn mailing lists.
The only [auth] section that exists is in the client's '~/.subversion/
config' file.
> If it does exist, that's on the server side, controlling svnserve,
> right?
>
>
It doesn't exist. But yes, repos/conf/svnserve.conf is only ever
noticed by the 'svnserve' program, nothing else.
>
>> 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?
>
What makes you think it's running? You have to set it up to run,
otherwise, it's not running. Installing a subversion package simply
means you get .exe's and libraries dropped onto your disk. No
daemons or services are set up for you.
To be sure, look at your list of processes. If svnserve.exe is
running, kill it. But I don't think it's going to be there, unless
you explicitly went through tricks to install it as a service.
>
>
>> 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.
>
Right.
> 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?
>
That's a personal preference. Note that, in subversion 1.2, however,
the win32 client now encrypts any passwords that it caches to disk.
So you might not have to worry so much.
>
>
>> 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?
Correct. When the client program accesses a file:/// url, it's just
opening the repository database files directly. If the OS doesn't
allow that, end of story.
>
> 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?
>
>
I'm not sure what you mean by "creates those". Yes, clients know
how to read the repository database "inherently". That's what it
means to access a file:/// url. If you don't want clients to do
that, then either (a) change file access permissions on the
repository, or (b) put the repository on a far-away computer, so that
clients can only access over a network.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun May 22 17:35:40 2005