Re: Respecting inherited Windows file permissions on file create

On 28.09.2013 23:17, Ivan Zhakov wrote:
> On 29 September 2013 00:25, Jason Kresowaty <jason_at_binarycoder.net> wrote:
>>> Subject: Re: Respecting inherited Windows file permissions on file create
>>> From: Ivan Zhakov <ivan_at_visualsvn.com>
>>> Date: Sat, September 28, 2013 3:29 pm
>>> Solution (2) is create temporary file in
>>> wc\a folder. In this case it will get proper inherited permissions
>>> from wc\a folder. You may try this solution in your test by modified
>>> permissions of wc\.svn\tmp directory.
>> Okay, now I see. That sounds like it would work, but would it make any
>> patch more or less invasive than it needs to be?
>>
>> I really don't mean to argue, but you seem to have not considered if
>> inserting a SetNamedSecurityInfo API call right after the file move
>> call would work (and be less invasive than other solutions), as the
>> Microsoft blogger I referenced previously described. But hey if the
>> tests pass, why should I complain!
>>
>> I could further describe ways to make this work "correctly" using
>> Windows APIs, including the issue with permissions that were assigned
>> directly on the file itself. These are probably not going to fit so
>> cleanly with the abstraction layer in place. And they are not going
>> to be as simple as calling one function with a bunch of NULL params
>> as would be the case for SetNamedSecurityInfo.
> SetNamedSecurityInfo() approach have several problems:
> 1. Platform depended code. Not a big deal, but makes testing and
> finding bugs more complicated.
> 2. File install operation become non-atomic. Subversion should handle
> SetNamedSecurityInfo() call failure.
>
>> Note, it is not feasible for me to set up a Windows svn development
>> environment to actually work on the svn code myself. So I would like
>> some guidance as to how to best assist with this, or if necessary
>> better explain this issue.
> Could you please file issue in Subversion issue tracker:
> http://subversion.tigris.org/issues/

This is not in fact a bug in Subversion; we've said a number of times
that we don't support maintaining different permissions on different
parts of the working copy, just as we don't, for example, support part
of the working copy being on a different filesystem.

The solution that jiggles the security descriptor is not acceptable. The
move-in-place *must* be atomic; all of our working copy code relies on
the assumption that it is atomic, and as far as I can remember, we don't
have code that can detect and recover from an incomplete move.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com