On 9/12/05, Jeff Squyres <jsquyres@open-mpi.org> wrote:
> On Sep 11, 2005, at 4:44 AM, Kalin KOZHUHAROV wrote:
>
> > Can you give a reason why only god can read the
> > test:/trunk/closed-directory ?
> > I perfectly understand why only he can write, but putting it "ro" is
> > normal, IMHO.
> > So far I cannot think of a case like that...
>
> Sure -- here's an easy one: some directories are simply not suitable
> for public access.
>
> For example, the specific repository that I'm thinking of is an
> academic project that is available for anonymous / read-only access.
> However, given the "publish [first] or perish" survival strategy in
> academia, sometimes we want to be able to do something new in a tree
> that the public cannot [yet] access. That is, in order to be "first"
> in academia, sometimes to have to operate in stealth mode for a little
> while, and when you finally have reportable results, open it to the
> world for public inspection, etc.
>
> I can think of a number of related scenarios for vendor-based SVN
> repositories, too.
>
> What it boils down to is: every project has different requirements.
> Now that one can have technology-enforced permissions in a source code
> repository (i.e., authz), you can bet that someone will have a scenario
> where locking out users from certain trees is a requirement (you could
> hack up similar scenarios in CVS, IIRC). This is just like the normal
> filesystem -- it's perfectly normal to have some users have limited (or
> no) access in a given tree. Why shouldn't that also apply to a
> repository?
>
> More specifically -- why *wouldn't* it be reasonable to have this kind
> of scenario?
>
> </philosophical_rant>
>
This also might be required when working on government contracts
or when dealing with customers' trade secrets.
[snip]
> >
> > Hmm, very interesting... I haven't run into this (and I didn't bother
> > testing
> > it - I trust you :-) but I don't like this behaviour as well. Which
> > side
> > is better is also a difficult argument, but something has to be done.
> > A first step might be to print warning MSG on `svn co`:
> >
> > WARNING: Directory bla-bla skipped. Access denied
> >
> > or similar. The next step might be implementing a new command option,
> > say
> > --fail-on-error that will abort the chekout on such warnings.
> >
> > Any other comments?
>
> I would agree -- printing warnings would be a good first step (in both
> cases -- co and cp). But it would be quite preferable to allow the cp
> to complete without erroring out. If you don't, it would be pretty
> hard for a user to complete the "cp" operation without a fairly
> complicated script that checks for which trees were fully copied,
> re-performs a subset of the cp, etc. Even worse, this would lead to
> lots of commits rather than a single, atomic commit.
>
> Just my $0.02...
>
Printed warnings are a form of security leak though. If a user does
not have access to the data, you may not want them to even know
it exists, so these warnings need to be a server side configuration
option.
Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 12 16:13:55 2005