Re: svnadmin create and not being method agnostic

2011-01-02 Thread Nico Kadel-Garcia 
On Sun, Jan 2, 2011 at 2:49 AM, Philip Prindeville
 wrote:
> On 1/1/11 8:29 PM, Nico Kadel-Garcia wrote:

>> To set up the first time for testing? No. To set up securely? Youch.
>> It's paide me some very remunerative consulting wages, becuase it took
>> someone as paranoid as me to clean it up. It's quite painful due to
>> lack of documentation of necessary single-user configurations, the
>> multiplicity of access technologies each with entirely different
>> access control tools, and the expectation that each admin will *of
>> course write their own little wrappers for standard, sensible
>> behavior.
>
> So you're ok being made redundant and slaughtering this cash-cow?  :-)
>
> -Philip
>

It's not cow. Subversion security is *goat*. Inexpensive to buy the
unprepared meat, but it;'s fairly gamey, risky for inexperienced
chefs, and raises suspicious eyebrows if anyone sees you with the big
hammer you need to tenderize it. But if the chef's time costs less
than the raw materials, some customers want it.

If we can get the goat meat tenderized before it lands in our
kitchens, that saves me time to make sure the busboys (of whatever
gender) aren't drinking all the table wine and writing the init
scripts in Perl.

RE: svnadmin create and not being method agnostic

2011-01-02 Thread Tony Sweeney 


-Original Message-
From: Nico Kadel-Garcia [mailto:nka...@gmail.com] 
Sent: 02 January 2011 12:55
To: Philip Prindeville
Cc: Ryan Schmidt; users@subversion.apache.org
Subject: Re: svnadmin create and not being method agnostic

>On Sun, Jan 2, 2011 at 2:49 AM, Philip Prindeville
> wrote:
>> On 1/1/11 8:29 PM, Nico Kadel-Garcia wrote:

>>> To set up the first time for testing? No. To set up securely? Youch.
>>> It's paide me some very remunerative consulting wages, becuase it took
>>> someone as paranoid as me to clean it up. It's quite painful due to
>>> lack of documentation of necessary single-user configurations, the
>>> multiplicity of access technologies each with entirely different
>>> access control tools, and the expectation that each admin will *of
>>> course write their own little wrappers for standard, sensible
>>> behavior.
>>
>> So you're ok being made redundant and slaughtering this cash-cow?  :-)
>>
>> -Philip
>>

>It's not cow. Subversion security is *goat*. Inexpensive to buy the
>unprepared meat, but it;'s fairly gamey, risky for inexperienced
>chefs, and raises suspicious eyebrows if anyone sees you with the big
>hammer you need to tenderize it. But if the chef's time costs less
>than the raw materials, some customers want it.

Ahem.  Subversion security is not goat.  Goat is fine eating, from the 
Caribbean to the middle east and central and southern Asia.  Subversion 
security is *roadkill*.  At the top end, Apache security is venison; a delicacy 
that many would be happy to pay for or indeed to hunt themselves.  At the low 
end, svnserve security is possum; hey, it's free, and it does the job so long 
as you hold your nose while you swallow.  I'll leave it to others to fill in 
the intermediate tiers/tieren*.

>If we can get the goat meat tenderized before it lands in our
>kitchens, that saves me time to make sure the busboys (of whatever
>gender) aren't drinking all the table wine and writing the init
>scripts in Perl.

Don't get me started on perl: "it was a hungry man that ate the first oyster".

Tony.
[*] A nod to our German correspondents.

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

Re: On commit attempt, Server sent unexpected return value (403 Forbidden) in response to CHECKOUT

2011-01-02 Thread Benjamin.Ortega 
That can't be right, since it works perfectly when I use the authz file by 
itself. When I add that apache location in, everything except the file that is 
indicated in that location works exactly as expected with the authz file in the 
order I have it.



Benjamin Ortega

Operations Systems Engineer
Wells Fargo Bank, Des Moines, IA
CORE Build & Deploy Team
benjamin.ort...@wellsfargo.com
☎ : 515-720-2700 (cell)‬
‪MAC: X2301-01X‬

‪‬

‪
This transmission may contain information that is confidential and/or 
proprietary. If you are not the individual or entity to which it is addressed, 
note that any review, disclosure, copying, retransmission, or other use is 
strictly prohibited. If you received this transmission in error, please notify 
the sender immediately and delete the material from your system.‬
‪


From: Tony Sweeney 
To: Ortega, Benjamin; users@subversion.apache.org 
Sent: Sat Jan 01 11:20:59 2011
Subject: RE: On commit attempt, Server sent unexpected return value (403 
Forbidden) in response to CHECKOUT




From: benjamin.ort...@wellsfargo.com [mailto:benjamin.ort...@wellsfargo.com]
Sent: 01 January 2011 17:13
To: users@subversion.apache.org
Subject: On commit attempt, Server sent unexpected return value (403 Forbidden) 
in response to CHECKOUT


I'm trying to integrate a SVN Authz authorization file with apache 
configuration files to provide a solution for not just directory level 
restrictions, but also file level restrictions. It's my understanding that the 
SVN Authorization file is not capable of handling file-specific restrictions, 
only directory level.

The SVN Authz file is set up and i'm able to use it with absolutely no issues 
what-so-ever. If I switch to using just the Apache Conf file by itself, it 
works exactly as expected with no issues. But if I combine them I get something 
very weird. Everything works just fine, except the trying to commit the file 
that was restricted by the following Location/Limit:



Require user my_username



I'm able to view, update, and checkout the file, and am able to do anything 
(checkout, commit, etc) to other files in the same directory, but when I 
attempt perform a commit of changes to the "RestrictedFile", I get the 
following error:
Error: Commit failed (details follow):
Error: Server sent unexpected return value (403 Forbidden) in response to 
CHECKOUT
Error: request for 
'/subversion/repo/!svn/ver/110/folder/structure/RestrictedFile'

the apache access log file gives me the following:
ip_address - - [30/Dec/2010:15:49:58 -0600] "OPTIONS 
/subversion/repo/folder/structure HTTP/1.1" 401 1337
ip_address - my_username [30/Dec/2010:15:49:59 -0600] "OPTIONS 
/subversion/repo/folder/structure HTTP/1.1" 200 -
ip_address - my_username [30/Dec/2010:15:49:59 -0600] "PROPFIND 
/subversion/repo/folder/structure HTTP/1.1" 207 816
ip_address - my_username [30/Dec/2010:15:49:59 -0600] "OPTIONS 
/subversion/repo/folder/structure HTTP/1.1" 200 195
ip_address - my_username [30/Dec/2010:15:49:59 -0600] "MKACTIVITY 
/subversion/repo/!svn/act/71f51505-a174-8349-ab61-843f80a40f8f HTTP/1.1" 201 234
ip_address - my_username [30/Dec/2010:15:49:59 -0600] "PROPFIND 
/subversion/repo/!svn/vcc/default HTTP/1.1" 207 414
ip_address - my_username [30/Dec/2010:15:49:59 -0600] "CHECKOUT 
/subversion/repo/!svn/bln/110 HTTP/1.1" 201 250
ip_address - my_username [30/Dec/2010:15:49:59 -0600] "PROPPATCH 
/subversion/repo/!svn/wbl/71f51505-a174-8349-ab61-843f80a40f8f/110 HTTP/1.1" 
207 469
ip_address - my_username [30/Dec/2010:15:49:59 -0600] "PROPFIND 
/subversion/repo/folder/structure HTTP/1.1" 207 526
ip_address - - [30/Dec/2010:15:49:59 -0600] "CHECKOUT 
/subversion/repo/!svn/ver/110/folder/structure/RestrictedFile HTTP/1.1" 403 1021
ip_address - my_username [30/Dec/2010:15:49:59 -0600] "DELETE 
/subversion/repo/!svn/act/71f51505-a174-8349-ab61-843f80a40f8f HTTP/1.1" 204 -

If I remove the  entry listed above, i'm able to commit just fine.

My svnauthz file basically has this:

[/]

* =

my_username = rw

The ordering is important.  Authz uses the fist match.  The first rule matches 
for all users, including ‘my_username’, so the second rule is ignored.  Try 
swapping the order of the directives, i.e.

[/]

my_username = rw

* =

If I change “* = “ to “* = r”, I get the same issue.  If I change it to “* = 
rw”, I’m able to commit.

Benjamin Ortega

Benjamin Ortega
--
Operations Systems Engineer
Wells Fargo Bank, Des Moines, IA
CORE Build & Deploy Team
• : benjamin.ort...@wellsfargo.com
• : 515-720-2700 (cell)

MAC: X2301-01X

This transmission may contain information that is confidential and/or 
proprietary. If you are not the individual or entity to which it is addressed, 
note that any review, disclosure, copying, retransmission, or other use is 
strictly prohibited. If you received this

Fine and secure dining, was Re: svnadmin create and not being method agnostic

2011-01-02 Thread Nico Kadel-Garcia 
[ Changing the subject line, this has gone off the deep end, partly my fault. ]

On Sun, Jan 2, 2011 at 7:50 PM, Tony Sweeney  wrote:
>
>
> -Original Message-
> From: Nico Kadel-Garcia [mailto:nka...@gmail.com]

>>It's not cow. Subversion security is *goat*. Inexpensive to buy the
>>unprepared meat, but it;'s fairly gamey, risky for inexperienced
>>chefs, and raises suspicious eyebrows if anyone sees you with the big
>>hammer you need to tenderize it. But if the chef's time costs less
>>than the raw materials, some customers want it.
>
> Ahem.  Subversion security is not goat.  Goat is fine eating, from the 
> Caribbean to the middle east and central and southern Asia.  Subversion 
> security is *roadkill*.  At the top end, Apache security is venison; a 
> delicacy that many would be happy to pay for or indeed to hunt themselves.  
> At the low end, svnserve security is possum; hey, it's free, and it does the 
> job so long as you hold your nose while you swallow.  I'll leave it to others 
> to fill in the intermediate tiers/tieren*.

Dude, I've eaten all of them. Goat is fine eating after you've hidden
the actual flavor of the goat, it's very tough meat and very gamey.
(High uric acid content.) Possum is, admittedly, even more gamey, at
least when I've had it. (Although I wasn't the cook.)

It's possible to do secure Subversion. Use svn+ssh access, disable or
block other services at the firewall, and keep it away from HTTP/HTTPS
in order to prevent UNIx or Linux client plaintext password storage.
It's just tricky and a lot of work, and you wind up having to do it
yourself due to the non-existent Subversion specific shell for
designated 'svn' users, and the lack of a CGI utility that would
support suexec operations for suexec based shell sites, and the fact
that "svnadmin hotcopy" doesn't preserve permissions or uid/gid
settings when you duplicate repositories.