Re: Recursive operations and authz

On 18.05.2015 15:08, C. Michael Pilato wrote: > On 05/14/2015 08:12 AM, Branko Čibej wrote: >> On 13.05.2015 15:24, C. Michael Pilato wrote: >>> I lean towards thinking that falls outside the scope of acceptable >>> changes in behavior in the 1.x line *unless* you can find a way to, >>> via configu

Re: Recursive operations and authz

On 05/14/2015 08:12 AM, Branko Čibej wrote: > On 13.05.2015 15:24, C. Michael Pilato wrote: >> I lean towards thinking that falls outside the scope of acceptable >> changes in behavior in the 1.x line *unless* you can find a way to, >> via configuration, allow administrators to explicitly toggle th

Re: Recursive operations and authz

On 16.05.2015 22:32, Ivan Zhakov wrote: >> In most CM workflows I've ever seen, a tag is assumed to be a read-only >> snapshot since its creation. FWIW, even with the required authz support >> in place, we still wouldn't have real tags, just as we don't have real >> branches; there's more to the se

Re: Recursive operations and authz

On 16 May 2015 at 22:30, Branko Čibej wrote: > On 16.05.2015 20:34, Ivan Zhakov wrote: >> On 15 May 2015 at 07:04, Stefan Fuhrmann >> wrote: >>> Thank you to everyone who answered! From what I gathered >>> so far is this: >>> >>> to (1) Requirering recursive or non-recursive write on a copy targ

Re: Recursive operations and authz

On 16.05.2015 20:34, Ivan Zhakov wrote: > On 15 May 2015 at 07:04, Stefan Fuhrmann wrote: >> Thank you to everyone who answered! From what I gathered >> so far is this: >> >> to (1) Requirering recursive or non-recursive write on a copy target >> should not make a difference to a typical authz s

Re: Recursive operations and authz

On 15 May 2015 at 07:04, Stefan Fuhrmann wrote: > Thank you to everyone who answered! From what I gathered > so far is this: > > to (1) Requirering recursive or non-recursive write on a copy target > should not make a difference to a typical authz setup with the > current /trunk code. However,

Re: Recursive operations and authz

On 15.05.2015 06:04, Stefan Fuhrmann wrote: > Thank you to everyone who answered! From what I gathered > so far is this: > > to (1) Requirering recursive or non-recursive write on a copy target > should not make a difference to a typical authz setup with the > current /trunk code. However, the

Re: Recursive operations and authz

Thank you to everyone who answered! From what I gathered so far is this: to (1) Requirering recursive or non-recursive write on a copy target should not make a difference to a typical authz setup with the current /trunk code. However, the provided paths *is* a change that should not be commi

Re: Recursive operations and authz

On 14.05.2015 14:12, Branko Čibej wrote: > With that in mind, we could teach the trunk/1.9 authz parser to > recognize an optional "[:config:]" section, in which we could add > options that control the behaviour of the rules in the authz file; a > 'copy-target-requires-recursive-access' option cou

Re: Recursive operations and authz

On 13.05.2015 15:24, C. Michael Pilato wrote: > I lean towards thinking that falls outside the scope of acceptable > changes in behavior in the 1.x line *unless* you can find a way to, > via configuration, allow administrators to explicitly toggle this new > paradigm. I've been thinking about a re

Re: Recursive operations and authz

On 13.05.2015 18:18, C. Michael Pilato wrote: > On 05/13/2015 10:35 AM, Branko Čibej wrote: >> On 13 May 2015 at 15:24, C. Michael Pilato >> wrote: >>> >>> Well, the use-case being broken here is kinda the obvious one: I >>> shouldn't have permission to create/delete

Re: Recursive operations and authz

On 05/13/2015 10:35 AM, Branko Čibej wrote: On 13 May 2015 at 15:24, C. Michael Pilato wrote: Well, the use-case being broken here is kinda the obvious one: I shouldn't have permission to create/delete some path /foo/bar (it's a system-critical file that shouldn't go away, or a password-bear

Re: Recursive operations and authz

On 13 May 2015 at 15:24, C. Michael Pilato wrote: > On 05/13/2015 02:21 AM, Stefan Fuhrmann wrote: >> Hi devs, >> >> At WANdisco, people have been playing with the new >> wildcard support for authz (see authz-performance branch) >> and ran into an interesting problem. > > [Details snipped. Welcom

Re: Recursive operations and authz

On 13 May 2015 at 12:19, Markus Schaber wrote: > Hi, Daniel, > >> Von: Daniel Shahaf [mailto:d...@daniel.shahaf.name] >> Stefan Fuhrmann wrote on Wed, May 13, 2015 at 08:21:37 +0200: >> > Hi devs, >> > >> > [...] >> > >> > (1) Is there something fundamentally wrong with this >> >approach, e.g.

Re: Recursive operations and authz

On 13 May 2015 at 12:08, Daniel Shahaf wrote: > Stefan Fuhrmann wrote on Wed, May 13, 2015 at 08:21:37 +0200: >> Hi devs, >> >> At WANdisco, people have been playing with the new >> wildcard support for authz (see authz-performance branch) >> and ran into an interesting problem. >> >> Today, recur

Re: Recursive operations and authz

On 05/13/2015 02:21 AM, Stefan Fuhrmann wrote: > Hi devs, > > At WANdisco, people have been playing with the new > wildcard support for authz (see authz-performance branch) > and ran into an interesting problem. [Details snipped. Welcome to 2004, where CollabNet ran into the same issues with the

Re: Recursive operations and authz

Stefan Fuhrmann wrote on Wed, May 13, 2015 at 08:21:37 +0200: > Hi devs, > > At WANdisco, people have been playing with the new > wildcard support for authz (see authz-performance branch) > and ran into an interesting problem. > > Today, recursive operations (COPY, DELETE and MOVE) > require recu

Re: Recursive operations and authz

On 13.05.2015 08:21, Stefan Fuhrmann wrote: > I have 3 questions: > > (1) Is there something fundamentally wrong with this >approach, e.g. braking major use-cases? It will certainly change how some authz files work, but that can be fixed. The net effect is be that users users would be able to