Re: .svn/wc.db as group writable

On Fri, Feb 24, 2017 at 2:03 AM, Branko Čibej <brane_at_apache.org> wrote:
> On 23.02.2017 23:59, Stefan wrote:
>> On 2/22/2017 17:13, Carlos Adean wrote:
>>> Hello,
>>>
>>>
>>> ----- Mensagem original -----
>>>> De: "Stefan Hett" <stefan_at_egosoft.com>
>>>> Para: users_at_subversion.apache.org
>>>> Enviadas: Segunda-feira, 20 de fevereiro de 2017 12:03:36
>>>> Assunto: Re: .svn/wc.db as group writable
>>>>
>>>> On 2/20/2017 1:40 PM, Carlos Adean wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On the specific issue: I'm not getting completely what problem you
>>>> are
>>>> facing. Are you expecting that SVN sets the group for .svn/wc.db
>>>> according to some group you set up by itself so it's readably/usable
>>>> by
>>>> other users than the one who did the repository checkout?
>>>>
>>>> Regards,
>>>> Stefan
>>>>
>>>>> So, I have set umask 002 and it works for all files except on
>>>>> .svn/wc.db - maybe I'm wrong and this is not a SVN problem.
>>>>>
>>>>>
>>>>> Again, I know this is unusual situation but is how we need to work.
>>>>>
>>>>>> Can you be a bit more specific what exactly you mean by "That's the
>>>>>> file that causes the problem[...]"? Do you get an SVN error when you
>>>>>> perform some operation from different accounts on the working copy
>>>>>> (in that case, please state the exact error message)? Alternatively:
>>>>>> Are you suggesting that after performing an SVN operation the
>>>>>> permissions of .svn/wc.db are changed (to what they were before the
>>>>>> call)?
>>> The default umask is 002 for all users and all of them are in the same group 'appgroup', which is the group that owns the repositories. The repositories are remote and one specific user creates local copies/clones. This user checks out a repository in a given directory (e.g. /home/appuser/software/trunk) using his own account. If a different user tries to svn update the same local copy of the repository, he gets errors of the type:
>>>
>>> svn: E155004: Working copy '/home/appuser/software/trunk' locked
>>> svn: E200031: sqlite: attempt to write a readonly database
>>> svn: E200031: sqlite: attempt to write a readonly database
>>> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
>>>
>>> my doubt is: if the umask is 002 why are the permissions for the group read-only on that file after checkout?
>>>
>> It certainly looks like some permission setup on your environment to me.
>> I don't have a test Linux machine running atm, so I can't test; but I'd
>> assume that files created in the user's home directly by default are
>> only granted full access by the current user, no? [1]
>
> No. They're granted whatever access is allowed by the umask. See
> https://en.wikipedia.org/wiki/Umask
>
> If the umask is 002 then all created files will, by default, allow read
> and write access to the user and the user's primary group. Neither
> Subversion nor SQLite tries to be smart in any way in this respect.
>
> There are other ways to control permissions on new files: your
> filesystem could have inheritable ACLs that prevent group-write
> permission to be granted, regardless of umask. Your SELinux
> configuration could do that, too.
>
> In any case, this is not a Subversion bug.

I can confirm that this "should work". At work we have a shared build
machine (Solaris), with hundreds of working copies for all kinds of
builds. All our developers can run builds there (including updating
those working copies or performing various working copy operations).
We're all part of the same unix group, and all use umask 002 on that
machine. This works fine (we've done this since SVN 1.5, we're now on
1.9.3).

This is what 'ls -l' says about it:

[[[
$ ls -l .svn
total 160146
-rw-rw-r-- 1 johndoe devgrp 3 Mar 21 2014 entries
-rw-rw-r-- 1 johndoe devgrp 3 Mar 21 2014 format
drwxrwxr-x 258 johndoe devgrp 258 Mar 21 2014 pristine/
drwxrwxr-x 2 johndoe devgrp 2 Feb 23 18:03 tmp/
-rw-rw-r-- 1 johndoe devgrp 81847296 Feb 23 18:03 wc.db
-rw-rw-r-- 1 johndoe devgrp 0 Feb 23 18:03 wc.db-journal
]]]

-- 
Johan