subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Corveleyn <>
Subject Re: .svn/wc.db as group writable
Date Fri, 24 Feb 2017 10:17:36 GMT
On Fri, Feb 24, 2017 at 2:03 AM, Branko ─îibej <> wrote:
> On 23.02.2017 23:59, Stefan wrote:
>> On 2/22/2017 17:13, Carlos Adean wrote:
>>> Hello,
>>> ----- Mensagem original -----
>>>> De: "Stefan Hett" <>
>>>> Para:
>>>> 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
>>>>>> 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
> 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

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


View raw message