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.
-- Brane
Received on 2017-02-24 02:03:33 CET