.svn/wc.db as group writable

Discussion:

Carlos Adean

2017-02-19 03:37:29 UTC

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

Stefan

2017-02-19 12:31:26 UTC

Permalink

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

Carlos Adean

2017-02-20 12:40:36 UTC

Permalink

Hi Stefan,

First of all thank you for the answer.

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

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

Stefan Hett

2017-02-20 15:03:36 UTC

Permalink

Post by Carlos Adean

Post by Stefan
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

Carlos Adean

2017-02-22 16:13:52 UTC

Permalink

Hello,

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

Enviadas: Segunda-feira, 20 de fevereiro de 2017 12:03:36
Assunto: Re: .svn/wc.db as group writable
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

Post by Carlos Adean
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.

Post by Stefan Hett
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
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?

Post by Carlos Adean

Post by Stefan Hett
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

Stefan

2017-02-23 22:59:25 UTC

Permalink

Post by Carlos Adean
Hello,
----- Mensagem original -----

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

Branko Čibej

2017-02-24 01:03:28 UTC

Permalink

Post by Stefan

Post by Carlos Adean
Hello,
----- Mensagem original -----

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

Johan Corveleyn

2017-02-24 10:17:36 UTC

Permalink

Post by Branko Äibej

Post by Stefan

Post by Carlos Adean
Hello,
----- Mensagem original -----

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

Nico Kadel-Garcia

2017-02-24 14:07:03 UTC

Permalink

Post by Johan Corveleyn
[[[
$ 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?

Johan Corveleyn

2017-02-24 15:34:26 UTC

Permalink

Post by Nico Kadel-Garcia

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

Nico Kadel-Garcia

2017-02-26 01:21:27 UTC

Permalink

Post by Johan Corveleyn

Post by Nico Kadel-Garcia
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?

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.

Post by Johan Corveleyn
(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?

Nico Kadel-Garcia

2017-02-24 14:04:23 UTC

Permalink

Post by Branko Äibej
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.

Carlos Adean

2017-03-15 13:34:43 UTC

Permalink

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

Enviadas: Quinta-feira, 23 de fevereiro de 2017 22:03:28
Assunto: Re: .svn/wc.db as group writable

Post by Stefan

Post by Carlos Adean
Hello,
----- Mensagem original -----

Enviadas: Segunda-feira, 20 de fevereiro de 2017 12:03:36
Assunto: Re: .svn/wc.db as group writable
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

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

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