.svn/wc.db as group writable

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

.svn/wc.db as group writable

Carlos Adean
Hi,

I imagining I have a problem with my svn version. After a bunch of tests, I cannot make svn checkout a product and set .svn/wc.db as group writable. I need to do that manually. That’s the file that causes the problem when a different user tries to update a product. Does anyone knows how to solve it?

OS: centOS-7

Name        : subversion
Arch        : x86_64
Version     : 1.7.14
Release     : 10.el7
Size        : 4.6 M
Repo        : installed
From repo   : anaconda



thanks,


--
C. Adean

Reply | Threaded
Open this post in threaded view
|

Re: .svn/wc.db as group writable

Stefan
On 2/19/2017 04:37, Carlos Adean wrote:

> Hi,
>
> I imagining I have a problem with my svn version. After a bunch of tests, I cannot make svn checkout a product and set .svn/wc.db as group writable. I need to do that manually. That’s the file that causes the problem when a different user tries to update a product. Does anyone knows how to solve it?
>
> OS: centOS-7
>
> Name        : subversion
> Arch        : x86_64
> Version     : 1.7.14
> Release     : 10.el7
> Size        : 4.6 M
> Repo        : installed
> From repo   : anaconda
>
>
>
> thanks,
>
>
> --
> C. Adean
Hi Carlos,

do you really need one working copy to be shared alongside multiple
users? I understand there might be cases where this is reasonable, but
usually I'd suggest to have one WC per user. I take it that if you
change this, this would solve the problem you are facing, no?

On the other side, the SVN version you are using is quite ancient and no
longer supported. I'd suggest you to upgrade to SVN 1.9.5 (or at least
to 1.8) if possible. Note that even SVN 1.7.14 is years old and not the
latest build of the 1.7-branch (which would be 1.7.22). At least
consider upgrading to SVN 1.7.22 to determine whether the problem you
are facing was a bug in SVN which got already solved.

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



smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .svn/wc.db as group writable

Carlos Adean
Hi Stefan,

First of all thank you for the answer.

----- Mensagem original -----

> De: "Stefan" <[hidden email]>
> Para: [hidden email]
> Enviadas: Domingo, 19 de fevereiro de 2017 9:31:26
> Assunto: Re: .svn/wc.db as group writable
>
> Hi Carlos,
>
> do you really need one working copy to be shared alongside multiple
> users? I understand there might be cases where this is reasonable,
> but
> usually I'd suggest to have one WC per user. I take it that if you
> change this, this would solve the problem you are facing, no?
>

You're right and I do this is not common, however there is a special case where the repos need to be shared with multiple users.

> On the other side, the SVN version you are using is quite ancient and
> no
> longer supported. I'd suggest you to upgrade to SVN 1.9.5 (or at
> least
> to 1.8) if possible. Note that even SVN 1.7.14 is years old and not
> the
> latest build of the 1.7-branch (which would be 1.7.22). At least
> consider upgrading to SVN 1.7.22 to determine whether the problem you
> are facing was a bug in SVN which got already solved.
>

I'll update as you suggested.

> 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.



Cheers,

--
Carlos
Reply | Threaded
Open this post in threaded view
|

Re: .svn/wc.db as group writable

Stefan Hett-2
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)?

Also understand that wc.db is an SQLite database. While that should in principle work with multiple users accessing the same database, the fact that you are running a very old version of SVN suggests that you might also use a very ancient version of SQLite (down to SQLite 3.8.1). It's possible that this is causing some trouble in your case due to bugs which have long been fixed in SQLite [1].

Last but not least, I certainly urge you to ensure that all the users accessing the working copy use a decent version of SVN (preferably 1.9.5) and do not share the same working copy under SVN versions which are too far apart from one another (for instance a client using SVN 1.8.0 and another one using SVN 1.9.5).
While this is supported by SVN (unless the working copy format changes), the fact of using different SQLite versions and other dependencies increases the risk for you to run into bugs/issues nobody else would expect to run into (which then increases the workload to troubleshoot such problems).

[1] https://www.sqlite.org/changes.html

-- 
Regards,
Stefan Hett
Reply | Threaded
Open this post in threaded view
|

Re: .svn/wc.db as group writable

Carlos Adean
Hello,


----- Mensagem original -----

> De: "Stefan Hett" <[hidden email]>
> Para: [hidden email]
> 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?

> > > Also understand that wc.db is an SQLite database. While that should
> > > in principle work with multiple users accessing the same database,
> > > the fact that you are running a very old version of SVN suggests
> > > that you might also use a very ancient version of SQLite (down to
> > > SQLite 3.8.1). It's possible that this is causing some trouble in
> > > your case due to bugs which have long been fixed in SQLite [1].
> > >
> > > Last but not least, I certainly urge you to ensure that all the users
> > > accessing the working copy use a decent version of SVN (preferably
> > > 1.9.5) and do not share the same working copy under SVN versions
> > > which are too far apart from one another (for instance a client
> > > using SVN 1.8.0 and another one using SVN 1.9.5).
> > > While this is supported by SVN (unless the working copy format
> > > changes), the fact of using different SQLite versions and other
> > > dependencies increases the risk for you to run into bugs/issues
> > > nobody else would expect to run into (which then increases the
> > > workload to troubleshoot such problems).
> > >
> > > [1] https://www.sqlite.org/changes.html
>

OK as soon as possible I'm going to update the version as you're suggesting.


Thank you!

--
Carlos

--
Carlos
Reply | Threaded
Open this post in threaded view
|

Re: .svn/wc.db as group writable

Stefan
On 2/22/2017 17:13, Carlos Adean wrote:

> Hello,
>
>
> ----- Mensagem original -----
>> De: "Stefan Hett" <[hidden email]>
>> Para: [hidden email]
>> 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]
Maybe someone who's more familiar with Linux permissions can pick this
one up and provide you further details, if needed.

[1]
http://unix.stackexchange.com/questions/95897/permissions-755-on-home-user

Regards,
Stefan


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .svn/wc.db as group writable

Branko Čibej
On 23.02.2017 23:59, Stefan wrote:

> On 2/22/2017 17:13, Carlos Adean wrote:
>> Hello,
>>
>>
>> ----- Mensagem original -----
>>> De: "Stefan Hett" <[hidden email]>
>>> Para: [hidden email]
>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: .svn/wc.db as group writable

Johan Corveleyn-3
On Fri, Feb 24, 2017 at 2:03 AM, Branko Čibej <[hidden email]> wrote:

> On 23.02.2017 23:59, Stefan wrote:
>> On 2/22/2017 17:13, Carlos Adean wrote:
>>> Hello,
>>>
>>>
>>> ----- Mensagem original -----
>>>> De: "Stefan Hett" <[hidden email]>
>>>> Para: [hidden email]
>>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: .svn/wc.db as group writable

Nico Kadel-Garcia-2
In reply to this post by Branko Čibej
On Thu, Feb 23, 2017 at 8:03 PM, Branko Čibej <[hidden email]> wrote:

> 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

SELinux, perhaps? Check "/etc/sysconfig/selinux" and prepare to reset
it to "warning" mode, and check the logs for SELinux errors? And there
are other compelling reasons to avoid putting shared workspaces in
individual user home directories.
Reply | Threaded
Open this post in threaded view
|

Re: .svn/wc.db as group writable

Nico Kadel-Garcia-2
In reply to this post by Johan Corveleyn-3
On Fri, Feb 24, 2017 at 5:17 AM, Johan Corveleyn <[hidden email]> wrote:

> [[[
> $ 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
> ]]]

You're definitely gont to want to set the directory permissions to
"2775", in order to ensure that files created inside the subdirectory
inherit the correct group permissions. Perhaps a "find . ! -group
devgrp" might show such files, if they already exist?
Reply | Threaded
Open this post in threaded view
|

Re: .svn/wc.db as group writable

Johan Corveleyn-3
On Fri, Feb 24, 2017 at 3:07 PM, Nico Kadel-Garcia <[hidden email]> wrote:

> On Fri, Feb 24, 2017 at 5:17 AM, Johan Corveleyn <[hidden email]> wrote:
>
>> [[[
>> $ 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
>> ]]]
>
> You're definitely gont to want to set the directory permissions to
> "2775", in order to ensure that files created inside the subdirectory
> inherit the correct group permissions. Perhaps a "find . ! -group
> devgrp" might show such files, if they already exist?

Thanks for the suggestion ... maybe I'll look into it.

But for now this doesn't pose a problem for us, because we always set
umask to 002 when devs login to this build machine, so any files they
create beneath those directories, or anywhere else when they do
"build-work", will be fine.

(there have been some rare occurrences when a dev changed their umask,
and then this falls over ... but we deal with those ad hoc for the
moment)

--
Johan
Reply | Threaded
Open this post in threaded view
|

Re: .svn/wc.db as group writable

Nico Kadel-Garcia-2
On Fri, Feb 24, 2017 at 10:34 AM, Johan Corveleyn <[hidden email]> wrote:

>> You're definitely gont to want to set the directory permissions to
>> "2775", in order to ensure that files created inside the subdirectory
>> inherit the correct group permissions. Perhaps a "find . ! -group
>> devgrp" might show such files, if they already exist?
>
> Thanks for the suggestion ... maybe I'll look into it.
>
> But for now this doesn't pose a problem for us, because we always set
> umask to 002 when devs login to this build machine, so any files they
> create beneath those directories, or anywhere else when they do
> "build-work", will be fine.

The difficulties include if a new subdirectory is created. That new
subdirectory will have group ownership by the developer, and
permissions of 0775. Hilarity can ensue. And the difficulty is true of
both Subversion repositories, and shared Subversion working copies.

> (there have been some rare occurrences when a dev changed their umask,
> and then this falls over ... but we deal with those ad hoc for the
> moment)

Perhaps a regular cron job could run, with alerts posting which files
or directories have erroneous permissions?
Reply | Threaded
Open this post in threaded view
|

Re: .svn/wc.db as group writable

Carlos Adean
In reply to this post by Branko Čibej


----- Mensagem original -----

> De: "Branko Čibej" <[hidden email]>
> Para: [hidden email]
> Enviadas: Quinta-feira, 23 de fevereiro de 2017 22:03:28
> Assunto: Re: .svn/wc.db as group writable
>
> On 23.02.2017 23:59, Stefan wrote:
> > On 2/22/2017 17:13, Carlos Adean wrote:
> >> Hello,
> >>
> >>
> >> ----- Mensagem original -----
> >>> De: "Stefan Hett" <[hidden email]>
> >>> Para: [hidden email]
> >>> 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
>

Hi folks,

Sorry for the long silence.

The permissions problem 'svn/wc.db as group writable' was solved after updating to the latest v1.9.5.


Thanks,

--
Carlos Adean
IT Team
linea.gov.br
skype: carlosadean