[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1547866 - /subversion/trunk/subversion/libsvn_fs_fs/rep-cache.c

From: Stefan Sperling <stsp_at_elego.de>
Date: Thu, 5 Dec 2013 16:01:51 +0100

On Thu, Dec 05, 2013 at 02:30:23PM +0000, Philip Martin wrote:
> Create a repository with group write access:
>
> (umask 002 ; svnadmin create repo)
>
> -rw-rw-r-- 1 pm pm 2 Dec 5 14:27 repo/db/current
> -r--r--r-- 1 pm pm 115 Dec 5 14:27 repo/db/revs/0/0
>
> Accidentally commit with umask denying all group/other access
>
> (umask 077 ; svn mkdir -mm file://`pwd`/repo/A)
>
> If we created the new files with umask permissions we would break future
> group access, but we copy permissions and the group access is preserved:
>
> -rw-rw-r-- 1 pm pm 2 Dec 5 14:28 repo/db/current
> -r--r--r-- 1 pm pm 115 Dec 5 14:27 repo/db/revs/0/0
> -r--r--r-- 1 pm pm 268 Dec 5 14:28 repo/db/revs/0/1
>
> Ideally we would like to do something similar for the rep-cache but at
> present we don't:
>
> (umask 077 ; svn import repo/format -mm file://`pwd`/repo/A/f)
>
> -rw-rw-r-- 1 pm pm 2 Dec 5 14:28 repo/db/current
> -rw------- 1 pm pm 3072 Dec 5 14:28 repo/db/rep-cache.db
> -r--r--r-- 1 pm pm 115 Dec 5 14:27 repo/db/revs/0/0
> -r--r--r-- 1 pm pm 268 Dec 5 14:28 repo/db/revs/0/1
> -r--r--r-- 1 pm pm 574 Dec 5 14:28 repo/db/revs/0/2
>
> I think what we need to do is copy the permissions of an existing
> read-write file such as db/current.

In the case of a long-running server like HTTPD respecting the server's
umask makes more sense to me.

But I agree that this approach makes sense to prevent misconfigured servers
(e.g. svnserve invcations over svn+ssh) from breaking group write access.
And since it matches existing behaviour, let's go for it.
I think that using the 'current' file as a permissions template is fine.
It must be present in any case for the repository to function.
Received on 2013-12-05 16:02:29 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.