You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Slade <ma...@gmail.com> on 2010/04/29 00:24:08 UTC
I believe I have found a bug with 'svn mv' + ACL-protected files.
Per your Issue Tracker Guidelines, I am seeking somebody who agrees
that this is a bug before I submit it.
Overview: For files, 'svn mv' does not properly inherit ACL
permissions from the parent directory.
Steps to reproduce (from a subversion working directory):
1. setfacl -d -m user:$USER:r-x .
2. touch foobar
3. svn add foobar
4. svn commit -m 'test' foobar
5. svn mv foobar barfoo
6. getfacl barfoo
If you check the ACL for barfoo after steps 2, 3, and 4, you will see
that it has properly inherited the user:jdoe:r-x permission. After
step 5, you will see that barfoo has not. You can circumvent this
behavior by using "mv" instead of "svn mv" in step 5. In this case,
you need to "svn delete foobar" and "svn add barfoo" before you can
commit the move.
Details:
CentOS release 5.4 (Final), svn 1.4.2 (from yum)
I'm not sure what else is relevant, so fire away if you have questions.
Mark
Re: I believe I have found a bug with 'svn mv' + ACL-protected files.
Posted by Mark Slade <ma...@gmail.com>.
All,
Apologies for the delayed response. Yes, my report was not about how the
files were created when deployed, but rather how they were created within a
working copy when an 'svn mv' was done. I probably wouldn't have considered
that it might be a bug if it weren't for the inconsistency: if you perform
those same steps against a *directory*, it retains the ACL as it would if
you had done a 'mv'.
Anyhow, I'm afraid I don't have the working environment to test this against
current, but if you would still like a bug report I would be happy to submit
one.
Mark
On Tue, May 4, 2010 at 3:46 AM, Stephen Butler <sb...@elego.de> wrote:
>
> On May 4, 2010, at 8:39 , Karl Fogel wrote:
>
> > Mark Slade <ma...@gmail.com> writes:
> >> Per your Issue Tracker Guidelines, I am seeking somebody who agrees
> >> that this is a bug before I submit it.
> >>
> >> Overview: For files, 'svn mv' does not properly inherit ACL
> >> permissions from the parent directory.
> >>
> >> Steps to reproduce (from a subversion working directory):
> >> 1. setfacl -d -m user:$USER:r-x .
> >> 2. touch foobar
> >> 3. svn add foobar
> >> 4. svn commit -m 'test' foobar
> >> 5. svn mv foobar barfoo
> >> 6. getfacl barfoo
> >>
> >> If you check the ACL for barfoo after steps 2, 3, and 4, you will see
> >> that it has properly inherited the user:jdoe:r-x permission. After
> >> step 5, you will see that barfoo has not. You can circumvent this
> >> behavior by using "mv" instead of "svn mv" in step 5. In this case,
> >> you need to "svn delete foobar" and "svn add barfoo" before you can
> >> commit the move.
> >>
> >> Details:
> >> CentOS release 5.4 (Final), svn 1.4.2 (from yum)
> >>
> >> I'm not sure what else is relevant, so fire away if you have questions.
> >
> > So just to clarify:
> >
> > The expectation is *not* that Subversion would version these ACLS, but
> > rather that, on the client side, an 'svn mv foo bar' would preserve
> > foo's ACLS so that bar has the same ACLs (locally).
> >
> > IOW, you would not expect that when the 'svn mv' is committed and
> > someone *else* checks out a working copy with the new bar in it, that
> > bar to have the ACLs, right?
> >
> > (Btw, I think it's better to just use "foo" and "bar" -- it's a bit hard
> > to keep track of "foobar" vs "barfoo", mentally :-) .)
> >
> > Stephen Butler, I saw your later followup, but were you clear on how
> > limited Mark's proposal actually is?
> >
> > -Karl
>
>
> Ooops, I see I misunderstood the proposal. Thanks, Karl.
>
> So, Mark, go ahead and open the issue. It'd be nice to reproduce it
> using the latest Subversion release (1.6.11).
>
> Cheers,
> Steve
>
> --
> Stephen Butler | Software Developer
> elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
> fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
> fax: +49 30 2345 8695 | http://www.elegosoft.com
> Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
> Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
>
>
Re: I believe I have found a bug with 'svn mv' + ACL-protected files.
Posted by Stephen Butler <sb...@elego.de>.
On May 4, 2010, at 8:39 , Karl Fogel wrote:
> Mark Slade <ma...@gmail.com> writes:
>> Per your Issue Tracker Guidelines, I am seeking somebody who agrees
>> that this is a bug before I submit it.
>>
>> Overview: For files, 'svn mv' does not properly inherit ACL
>> permissions from the parent directory.
>>
>> Steps to reproduce (from a subversion working directory):
>> 1. setfacl -d -m user:$USER:r-x .
>> 2. touch foobar
>> 3. svn add foobar
>> 4. svn commit -m 'test' foobar
>> 5. svn mv foobar barfoo
>> 6. getfacl barfoo
>>
>> If you check the ACL for barfoo after steps 2, 3, and 4, you will see
>> that it has properly inherited the user:jdoe:r-x permission. After
>> step 5, you will see that barfoo has not. You can circumvent this
>> behavior by using "mv" instead of "svn mv" in step 5. In this case,
>> you need to "svn delete foobar" and "svn add barfoo" before you can
>> commit the move.
>>
>> Details:
>> CentOS release 5.4 (Final), svn 1.4.2 (from yum)
>>
>> I'm not sure what else is relevant, so fire away if you have questions.
>
> So just to clarify:
>
> The expectation is *not* that Subversion would version these ACLS, but
> rather that, on the client side, an 'svn mv foo bar' would preserve
> foo's ACLS so that bar has the same ACLs (locally).
>
> IOW, you would not expect that when the 'svn mv' is committed and
> someone *else* checks out a working copy with the new bar in it, that
> bar to have the ACLs, right?
>
> (Btw, I think it's better to just use "foo" and "bar" -- it's a bit hard
> to keep track of "foobar" vs "barfoo", mentally :-) .)
>
> Stephen Butler, I saw your later followup, but were you clear on how
> limited Mark's proposal actually is?
>
> -Karl
Ooops, I see I misunderstood the proposal. Thanks, Karl.
So, Mark, go ahead and open the issue. It'd be nice to reproduce it
using the latest Subversion release (1.6.11).
Cheers,
Steve
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Re: I believe I have found a bug with 'svn mv' + ACL-protected files.
Posted by Karl Fogel <kf...@red-bean.com>.
Mark Slade <ma...@gmail.com> writes:
>Per your Issue Tracker Guidelines, I am seeking somebody who agrees
>that this is a bug before I submit it.
>
>Overview: For files, 'svn mv' does not properly inherit ACL
>permissions from the parent directory.
>
>Steps to reproduce (from a subversion working directory):
>1. setfacl -d -m user:$USER:r-x .
>2. touch foobar
>3. svn add foobar
>4. svn commit -m 'test' foobar
>5. svn mv foobar barfoo
>6. getfacl barfoo
>
>If you check the ACL for barfoo after steps 2, 3, and 4, you will see
>that it has properly inherited the user:jdoe:r-x permission. After
>step 5, you will see that barfoo has not. You can circumvent this
>behavior by using "mv" instead of "svn mv" in step 5. In this case,
>you need to "svn delete foobar" and "svn add barfoo" before you can
>commit the move.
>
>Details:
>CentOS release 5.4 (Final), svn 1.4.2 (from yum)
>
>I'm not sure what else is relevant, so fire away if you have questions.
So just to clarify:
The expectation is *not* that Subversion would version these ACLS, but
rather that, on the client side, an 'svn mv foo bar' would preserve
foo's ACLS so that bar has the same ACLs (locally).
IOW, you would not expect that when the 'svn mv' is committed and
someone *else* checks out a working copy with the new bar in it, that
bar to have the ACLs, right?
(Btw, I think it's better to just use "foo" and "bar" -- it's a bit hard
to keep track of "foobar" vs "barfoo", mentally :-) .)
Stephen Butler, I saw your later followup, but were you clear on how
limited Mark's proposal actually is?
-Karl
Re: I believe I have found a bug with 'svn mv' + ACL-protected files.
Posted by Stephen Butler <sb...@elego.de>.
On Apr 29, 2010, at 16:00 , Mark Slade wrote:
> Bob,
>
> Thanks for the tip. My mistake.
>
> Mark
>
> On Thu, Apr 29, 2010 at 9:50 AM, Bob Archer <Bo...@amsi.com> wrote:
>
>>> Per your Issue Tracker Guidelines, I am seeking somebody who agrees
>>> that this is a bug before I submit it.
>>>
>>> Overview: For files, 'svn mv' does not properly inherit ACL
>>> permissions from the parent directory.
>>>
>>
>> svn 1.4 is MILES old. I'm not a core dev here but I expect that you should
>> attempt this issue with the current 1.6.11 before reporting it as a bug.
>>
Hi Mark,
I think this problem is out of scope for Subversion.
On Unix-ish systems, Subversion supports the executable flag. On
all operating systems, Subversion sets a file read-only if the file has
the 'svn:needs-lock' property set.
Tweaking file/dir permissions, setting ACLs, and other OS-specific
features should be handled by deployment tools or sysadmin
automation (e.g., cfengine).
Regards,
Steve
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Re: I believe I have found a bug with 'svn mv' + ACL-protected files.
Posted by Mark Slade <ma...@gmail.com>.
Bob,
Thanks for the tip. My mistake.
Mark
On Thu, Apr 29, 2010 at 9:50 AM, Bob Archer <Bo...@amsi.com> wrote:
> > Per your Issue Tracker Guidelines, I am seeking somebody who agrees
> > that this is a bug before I submit it.
> >
> > Overview: For files, 'svn mv' does not properly inherit ACL
> > permissions from the parent directory.
> >
> > Steps to reproduce (from a subversion working directory):
> > 1. setfacl -d -m user:$USER:r-x .
> > 2. touch foobar
> > 3. svn add foobar
> > 4. svn commit -m 'test' foobar
> > 5. svn mv foobar barfoo
> > 6. getfacl barfoo
> >
> > If you check the ACL for barfoo after steps 2, 3, and 4, you will see
> > that it has properly inherited the user:jdoe:r-x permission. After
> > step 5, you will see that barfoo has not. You can circumvent this
> > behavior by using "mv" instead of "svn mv" in step 5. In this case,
> > you need to "svn delete foobar" and "svn add barfoo" before you can
> > commit the move.
> >
> > Details:
> > CentOS release 5.4 (Final), svn 1.4.2 (from yum)
> >
> > I'm not sure what else is relevant, so fire away if you have questions.
>
> svn 1.4 is MILES old. I'm not a core dev here but I expect that you should
> attempt this issue with the current 1.6.11 before reporting it as a bug.
>
> BOb
>
RE: I believe I have found a bug with 'svn mv' + ACL-protected
files.
Posted by Bob Archer <Bo...@amsi.com>.
> Per your Issue Tracker Guidelines, I am seeking somebody who agrees
> that this is a bug before I submit it.
>
> Overview: For files, 'svn mv' does not properly inherit ACL
> permissions from the parent directory.
>
> Steps to reproduce (from a subversion working directory):
> 1. setfacl -d -m user:$USER:r-x .
> 2. touch foobar
> 3. svn add foobar
> 4. svn commit -m 'test' foobar
> 5. svn mv foobar barfoo
> 6. getfacl barfoo
>
> If you check the ACL for barfoo after steps 2, 3, and 4, you will see
> that it has properly inherited the user:jdoe:r-x permission. After
> step 5, you will see that barfoo has not. You can circumvent this
> behavior by using "mv" instead of "svn mv" in step 5. In this case,
> you need to "svn delete foobar" and "svn add barfoo" before you can
> commit the move.
>
> Details:
> CentOS release 5.4 (Final), svn 1.4.2 (from yum)
>
> I'm not sure what else is relevant, so fire away if you have questions.
svn 1.4 is MILES old. I'm not a core dev here but I expect that you should attempt this issue with the current 1.6.11 before reporting it as a bug.
BOb