File level ACL

[Pierre Belzile <pi...@idilia.com>]

Thanks for the suggestions yesterday. However, no solutions were
offered. For a recap:
   dir1/aClass.h (should be readable to all users of the library)
   dir1/aClass.cc (should only be visible to selected users working on
it's library)

Users of the library cannot view the source code in aClass.cc. They can
only read aClass.h. Library developpers can r/w everything.

My understanding is that access controlthrough the Apache interface
can't cut it. mod_auth_svn uses a datafile that can contain directories
only. My suggestion would be to add file patterns as well. For example,
I would say "*.h" is "r" for "*". 

It's ironic that CVS does this. (Using proper permissions on the files.)
I can't move to subversion until something equivalent (hopefully
better!) exists.

Cheers, Pierre

Re: File level ACL

[Gary Feldman <ga...@memento-inc.com>]

----- Original Message ----- 
>From: Pierre Belzile

>My understanding is that access controlthrough the Apache interface can't
cut it. mod_auth_svn

There's an obvious alternative, which you may not like because it requires
restructuring your tree, but it has certain advantages:  Put the .h files in
a separate include directory, and then use Apache's directory protections.

This is a fairly common source tree pattern.  It's sometimes done for the
same reason in a different context (i.e., it's easier to manage UNIX
permissions this way).  It also makes it easier to set up include flags for
the compiler (e.g. just generate automatically from all the include
directories).  It makes packaging of kits easier (just include the /include
directory instead of identifying files individually).  It makes it much
easier to verify that permissions are what you want them to be.  It makes it
easier to have private include files (instead of using .hh or something
similar).  It takes a bit of getting used to, particularly since most people
never learn this approach in school, but it's probably worth it - especially
in your case where you have such a strong requirement.

Gary

Gary



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: File level ACL

[Ben Collins-Sussman <su...@collab.net>]

On Fri, 2004-03-26 at 08:43, Travis P wrote:
> On Mar 26, 2004, at 7:49 AM, Pierre Belzile wrote:
> 
> >  It's ironic that CVS does this. (Using proper permissions on the 
> > files.) I can't move to subversion until something equivalent 
> > (hopefully better!) exists.
> 
> Proper for your particular standard Unix environment I'm guessing.  As 
> I understand it, Subversion uses APR for all filesystem access for 
> great portability.  Not all filesystems share the same permission model 
> (Window's filesystems?), including some Unix systems.  

Um, I think there's some confusion here.  CVS can restrict permission on
specific files because the repository is just a bunch of RCS files.  The
administrator goes in and hand-edits the permissions on *.c or *.h by
hand.

The SVN repository has only "imaginary" files in a database.  There's no
concept of permissions within this virtual filesystem.  Maybe someday
the database will have a real ACL system, but for now, all permissions
are controlled by programs outside the repository, such as apache or
svnserve or pre-commit hooks.

Just as Pierre suggests, a good feature to add to mod_authz_svn would be
wildcards on directory/file patterns.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: File level ACL

[Travis P <sv...@castle.fastmail.fm>]

On Mar 26, 2004, at 7:49 AM, Pierre Belzile wrote:

>  It's ironic that CVS does this. (Using proper permissions on the 
> files.) I can't move to subversion until something equivalent 
> (hopefully better!) exists.

Proper for your particular standard Unix environment I'm guessing.  As 
I understand it, Subversion uses APR for all filesystem access for 
great portability.  Not all filesystems share the same permission model 
(Window's filesystems?), including some Unix systems.   e.g. AFS has 
per-directory ACLs only (there is a trick with symlinks so that AFS 
permissions can appear to be file-based; come to think of it, the same 
trick might well work for Subversion if Subversion handled symlinks; I 
wish it did; creating a workaround using properties and a 
client-wrapping script is something I'm going to have to do I think but 
there are some inefficiencies that may be hard to get around; please 
excuse this really long parenthetical...).  I myself am a fan of 
per-directory privileges because it's so much easier to use and manage 
and avoid mistakes.  I've also used IBM's DFS file system for years 
which is a very full-featured combination of per-directory/per-file 
ACLs plus it honors standard Unix permission bits.  It's a real 
nightmare to use in practice.
-Travis


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: File level ACL

["Robert M.Zigweid" <rz...@zigweid.net>]

On Mar 26, 2004, at 8:49 AM, Pierre Belzile wrote:

>  Thanks for the suggestions yesterday. However, no solutions were 
> offered. For a recap:
>     dir1/aClass.h (should be readable to all users of the library)
>     dir1/aClass.cc (should only be visible to selected users working 
> on it's library)
>
>  Users of the library cannot view the source code in aClass.cc. They 
> can only read aClass.h. Library developpers can r/w everything.
>
>  My understanding is that access controlthrough the Apache interface 
> can't cut it. mod_auth_svn uses a datafile that can contain 
> directories only. My suggestion would be to add file patterns as well. 
> For example, I would say "*.h" is "r" for "*".
>
>  It's ironic that CVS does this. (Using proper permissions on the 
> files.) I can't move to subversion until something equivalent 
> (hopefully better!) exists.
>
>  Cheers, Pierre
I would actually probably prefer to take it one step further and allow 
wildcards in general in this list.  As well as limiting file access, it 
would be convenient to be able to have some permissions such as 
/*/branch/ type permissions where the * would represent a project 
(using the /projectA/trunk style structure).

Just a thought.
-- 
Robert M. Zigweid                           rzigweid@zigweid.net
                                             http://rzigweid.zigweid.net


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org