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

Re: WC permissions

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-12-13 19:41:41 CET

Branko ─Œibej <brane@xbc.nu> writes:

> Philip Martin wrote:
>>Branko ├„┼’ibej <brane@xbc.nu> writes:
>>>The only way I know to do this on Unix (if your filesystem doesn't have
>>>inheritable ACLs) is to put all your users into the same group (doesn't
>>>have to be the primary group), use umask 002 and set the sticky-group
>>>bit on the directories in the subversion WC.
>>On my system chmod(2) says
>> "The effective UID of the process must be zero or must match the
>> owner of the file."
>>so the sticky bit does not appear to solve the shared working copy
>>problem. It does solve the shared repository problem.
> Hm? What does chmod have to do with sticky group ownership?

Perhaps I misunderstood, I thought you were suggesting that group
access (hence the sticky bit) would be sufficient for shared working

> What I described works on every Unix-ish system i've laid my hands
> on. Not many, I'll admit -- only AIX, HP-UX, Solaris, FreeBSD and
> Linux.

On my Linux box only the owner of a file can change the permissions on
that file. So it doesn't matter how I set up groups, umask or sticky
bits, only the wc owner can run update.

$ umask
$ groups
$ svnadmin create repo
$ svn co file://`pwd`/repo wc
$ chmod -R +t wc
$ svn mkdir -m "" file://`pwd`/repo/foo
$ su corris
$ newgrp pm
$ groups
pm corris
$ umask
$ svn up wc
../svn/subversion/libsvn_subr/io.c:749: (apr_err=1)
svn: Can't set file 'wc/.svn/entries' read-write: Operation not permitted

What's really nasty is that this leaves wc/.svn/tmp/entries owned by
the "other" user and it gets reused when the wc owner runs update.
Thus when wc/.svn/tmp/entries gets renamed to wc/.svn/entries it is
still owned by the other user, and so the wc owner cannot set its
permissions and the update fails.

Shared working copies are not really possible.

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 13 19:53:58 2003

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.