[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

anon-access=read && authz [/] *= . (not a cry for help)

From: Zachery Hostens <zacheryph_at_gmail.com>
Date: 2006-07-20 00:52:17 CEST

What i Want:
i want to run 1 repository, giving anonymous users access to specific
directories, but leaving the rest private. I also do /not/ want to
give anonymous users access to / for log or list or otherwise.

below is the configuration id like[/have],
  whats wrong and ways it "works",
  what i think is wrong with authz,
  how i think it could be resolved,
  and a little extra id like to see in authz ;)

// configuration
==svnserve.conf
  anon-access = read
  auth-access = write
  password-db = passwd
  authz-db = authz
  realm = My First Repository
==passwd
  [users]
  zac = password
==authz
[/test]
zac = rw
* = r
[/emech]
zac = rw
// end configuration

// whats good and wrong
GOOD: anonymous can ls and co /test
GOOD: anonymous can NOT co /emech
GOOD: zac can ls /test and /emech
GOOD: zac can co /test
BAD!: zac can NOT co /emech

motion_at_dream ~ $ svn co svn://localhost/emech
svn: Not authorized to open root of edit operation

// ways it doesnt/does work
  * adding [/] zac = rw
this does NOT work. does not effect anonymous operations and still
fails to let zac co /emech

  * adding [/] * = r
this DOES work, but is not what i /want/
this DOES let zac co /emech, at the cost of giving anonymous ls/log access to /
im a pretty security oriented person (partial paranoia) and would
rather /NOT/ show people stuff they dont need to see. (dont show your
kid a cookie if you dont intend on giving it to him.) so i dont see
this work-around as an acceptable one.

  * setting anon-access = none
this DOES work, but is not what i /want/
this DOES let zac co /emech, at the cost of not giving anon access at all

// what i think is wrong with authz
http://svn.haxx.se/users/archive-2006-02/1208.shtml
primarily looking at step 2 of authorization. zac is authorized to
read /emech (AND / when added) but authz still fails to see this
point.

authz is doing something very funny with the / directory and
processing '*' entries.
anonymous CAN checkout /test WITHOUT read access to /
zac CANNOT checkout /emech WITH access to / and /emech (as tested above)

i dont know the svn/authz code well enough (yet) to see why authz is
treating anonymous users so special. anonymous users get thrown into
'*' obviously, but this does not explain why * does NOT need read on /
to checkout /test and why zac needs *=r access on / to co /emech.

// how i think it may be fixed
stop treating anonymous so special. requiring *=r on / defeats half
the purpose of authz in my eyes. anon-access should not effect an
authorized user with access from checking out a directory. especially
seeing as anonymous themselves do not even need read on / to checkout
stuff.

// something special id like in authz
this kind of goes hand in hand with ways to fix (sort of)
i wouldnt mind giving authorized users r to / (not that that fixes the
problem)[or giving all authorized users access to a 'play' area] but
there is no easy way to do this that i see currently. are there any
plans to have a generic group, like @anon and @auth? if not meh, just
an idea i thought of at the last minute.

// final words
ive seen stuff related to this over the past 6 months in the mailing
list. i was told an "easy" way around this is to create a guest
account. but then id ask whats the point of anonymous access if the
acl's crumble when you try to restrict them or do anything with them.

id like to get feedback on this, before i go to submit an issue in the
bug tracker. please reply with any
questions/comments/complains/agreements/etc that may or may not help
me out. (please reply-all/cc me as im not currently on the mailing
list)

-- 
Zachery Hostens <zacheryph@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jul 20 02:23:34 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.