Hi Carlos,
I think this is related to the defect I raised:
http://subversion.tigris.org/issues/show_bug.cgi?id=2907
Regards,
David.
--
David Grierson
JPMorgan - IB Architecture - Source Code Management Consultant
GDP 228-5574 / DDI +44 141 228 5574 / Email david.x.grierson_at_jpmorgan.com
Alhambra House 6th floor, 45 Waterloo Street, Glasgow G2 6HS
"Carlos Vieira" <carlos_at_boreste.us>
26/08/2008 12:08
To
"SVN users" <users_at_subversion.tigris.org>
cc
Subject
Fwd: AuthZ file rules not being respected
Sorry David, sent this mail only to you before without noticing.
David,
Thanks for the reply, but I just tried file:// access to sort out a
problem with my Apache config. Normally only apache (and backup
operators) have filesystem access to my repository.
The problem I am getting is:
user1 can access http://server/svn/whatever (good)
council1 can access http://server/svn/council (good)
user1 can access http://server/svn/council (BAD)
user1 shouldn't be able to access council-only area, but they are.
They can checkout, they can see the contents in the browser, etc. I
haven't tried commits, but I don't want any access, neither read nor
write.
[/]
* =
@users = rw
[/council]
* =
# I thought the following line disabled @users to access /council
#althogether, but it isn't working
@users =
@council = rw
- Vieira
On Tue, Aug 26, 2008 at 1:47 AM, David Weintraub <qazwart_at_gmail.com>
wrote:
>
> On Mon, Aug 25, 2008 at 6:16 PM, Carlos Vieira <carlos_at_boreste.us>
wrote:
> > Hello all
> >
> > I have a single-repository multiple-project setup. In it, a subpath on
> > my SVN repos should be readable/writeable only by a few users (on
> > group council), while the rest of the repository catches a wider
> > audience (group users). However, users from the group users can read
> > council-only files through both file:// and http:// URIs.
>
> You should only use file:/// access on a personal repository where
> you're the only one accessing the repository, and you don't feel like
> running a server. Heck, I'm the administrator and have root access on
> my Subversion server, and I never access the repository via file:///.
> When a user has file:/// access, it means they can directly mess up
> the repository itself, either on purpose, or accidently (like checking
> out a Subversion working directory in the middle of the repository.
>
> Since you're using http://, the repository does not have to be
> readable or writable to the group "users". That would prevent the
> users from accessing the repository via the file:/// protocol. Set the
> permission of the files in the /my/svn directory tree to 600 or 644,
> and make the ownership and group of the files to be the Apache user
> running the httpd daemon. Set the umask for the Apache user to make
> sure that files created don't have group or other "write" permission.
> That way no one has file:/// access to your repository.
>
> If you really, really need to have your Council group have file:///
> access, you could create a group called "council" and make all council
> users part of that group. Then make this the group that your Apache
> server uses. Set the umask of the server to 002, and make all files in
> the /my/svn directory tree 664. (Files only! Directories must be 775!)
>
> However, I don't even use the file:/// protocol when I am accessing my
> own private Subversion repository on my server. I still fire up a
> svnserve process and use svn://.
>
> --
> David Weintraub
> qazwart_at_gmail.com
--
Carlos Vieira
+55(48)3025.4222
..:: Boreste ::. Sistemas Embarcados -- Do Conceito à Inovação
www.boreste.com
--
Carlos Vieira
+55(48)3025.4222
..:: Boreste ::. Sistemas Embarcados -- Do Conceito à Inovação
www.boreste.com
Generally, this communication is for informational purposes only
and it is not intended as an offer or solicitation for the purchase
or sale of any financial instrument or as an official confirmation
of any transaction. In the event you are receiving the offering
materials attached below related to your interest in hedge funds or
private equity, this communication may be intended as an offer or
solicitation for the purchase or sale of such fund(s). All market
prices, data and other information are not warranted as to
completeness or accuracy and are subject to change without notice.
Any comments or statements made herein do not necessarily reflect
those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.
Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to UK legal entities.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-26 13:14:18 CEST