You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Dave Merrill <dm...@usa.net> on 2005/05/20 22:49:28 UTC
SVN not asking for authorization
SVN newb here, aplogies if this is all obvious...
I'm not sure if this is a Subversion or TortoiseSVN issue, but TortoiseSVN
doesn't seem to require any kind of authorization to access a file-based
repository on the same machine (win2k).
svn/repositoryname/conf/svnserve.conf contains the following (among other
things):
----------------
[general]
password-db = passwd
realm = Subversion repositories
anon-access = none
[auth]
store-auth-creds = no
----------------
In that same dir, the file passwd contains the following (only):
----------------
[users]
someusername = somepassword
----------------
I thought these settings should mean that anonymous users weren't allowed,
that only the user 'someusername' was allowed, and they they'd have to
present the password 'somepassword' to get in.
TortoiseSVN seems to be able to do anything it wants to that repository,
without any of that.
I've clicked the 'Clear Auth Cache' btn in TortoiseSVN, and restarted my
machine. I've also checked all directories under here:
C:\Documents and Settings\MyUserName\Application Data\Subversion\auth
...to see if any auth info was cached there, and they're all empty.
Another odd thing is that all changes show up in svn as made by the login
user of this machine, which is *not* a name I would have used for the
repository login. I'd much prefer that they appeared under the name I used
in the svn passwd file, and besides, that seems to indicate that tortoise is
being authorized on some other level.
Am I doing something wrong here? Does windows short-circuit svn's
authorization scheme for repositories on the same machine (just guessing).
Is this about svn or tortoise? Anything else I should try?
Thanks for any help,
Dave Merrill
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN not asking for authorization
Posted by Ben Collins-Sussman <su...@collab.net>.
On May 21, 2005, at 1:19 PM, Ben Collins-Sussman wrote:
> 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.
Oops, sorry, I mean chapter 7.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN not asking for authorization
Posted by Ben Collins-Sussman <su...@collab.net>.
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
RE: SVN not asking for authorization
Posted by Dave Merrill <dm...@usa.net>.
> > 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
Re: SVN not asking for authorization
Posted by Ben Collins-Sussman <su...@collab.net>.
On May 21, 2005, at 10:00 AM, Dave Merrill wrote:
>
> 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. :-)
There are two sides of the network: the server side, and the client
side.
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. In the case of Apache, there's an authorization 'module'
you need to install. In the case of svnserve, authorization is
controlled by the 'svnserve.conf' file within the repository's conf/
subdirectory.
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.
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 authorziation, 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.
>
> Is it possible to shut down all access except through apache
> (leaving aside
> direct edits of the files in the repo itself)? In that
> configuration, I
> could use an http url locally, and also allow others access when I
> want to,
> both through a single set of access controls in apache. Make sense?
>
>
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: SVN not asking for authorization
Posted by Dave Merrill <dm...@usa.net>.
Thanks for your help, and my apologies such newbitude. Some
replies/questions:
> 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.
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?
> Second, that file is only ever used by the 'svnserve' server
> program. That's it. Not apache, and certainly not direct (file:///)
> access.
I knew it wasn't used by apache, but didn't realize that file:/// access
wasn't served by svnserve. That is clear from the architecture diagram in
the docs though; my bad.
Is it possible to shut down all access except through apache (leaving aside
direct edits of the files in the repo itself)? In that configuration, I
could use an http url locally, and also allow others access when I want to,
both through a single set of access controls in apache. Make sense?
> Third, there's no such thing as access control when your client
> touches the repository directly via file:///. It's meaningless; who
> would enforce it? Even if the client saw some variables that meant,
> "don't change things", the user could always open the repository
> files directly in a text editor and and start mucking with things.
> In other words, the only permissioning going on are operating-system
> perms on the database files. That's it. Set the ACLs appropriately,
> and let your OS do the work.
I'm aware that with the repository on the same machine, I could just edit
files in the repository directly. But that would defeat the purpose of
having scm at all. It's in my best interest to treat some of the files on my
own disk as if the repository was elsewhere.
Thanks again for your help, very much appreciated,
Dave Merrill
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN not asking for authorization
Posted by Ben Collins-Sussman <su...@collab.net>.
On May 20, 2005, at 5:49 PM, Dave Merrill wrote:
> SVN newb here, aplogies if this is all obvious...
>
> I'm not sure if this is a Subversion or TortoiseSVN issue, but
> TortoiseSVN
> doesn't seem to require any kind of authorization to access a file-
> based
> repository on the same machine (win2k).
>
> svn/repositoryname/conf/svnserve.conf contains the following (among
> other
> things):
>
> ----------------
> [general]
> password-db = passwd
> realm = Subversion repositories
> anon-access = none
>
> [auth]
> store-auth-creds = no
There are multiple confusions here...
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.
Second, that file is only ever used by the 'svnserve' server
program. That's it. Not apache, and certainly not direct (file:///)
access.
Third, there's no such thing as access control when your client
touches the repository directly via file:///. It's meaningless; who
would enforce it? Even if the client saw some variables that meant,
"don't change things", the user could always open the repository
files directly in a text editor and and start mucking with things.
In other words, the only permissioning going on are operating-system
perms on the database files. That's it. Set the ACLs appropriately,
and let your OS do the work.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org