[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: Sigfred Håversen <suselist_at_mumak.com>
Date: 2003-12-10 01:41:49 CET

From the man page for sticky on http://www.openbsd.org/cgi-bin/man.cgi :

     A directory whose `sticky bit' is set becomes an append-only directory,
     or, more accurately, a directory in which the deletion of files is re-
     stricted. A file in a sticky directory may only be removed or renamed by
     a user if the user has write permission for the directory and the user is
     the owner of the file, the owner of the directory, or the superuser.
     This feature is usefully applied to directories such as /tmp which must
     be publicly writable but should deny users the license to arbitrarily
     delete or rename each others' files.

     Any user may create a sticky directory. See chmod(1) for details about
     modifying file modes.

/Sigfred

On Wednesday 10 December 2003 01:23, y2w2de9j001@sneakemail.com wrote:
> I think I've done all of this and I still get problems. I've never set the
> sticky bit on a directory so please correct me if this was the wrong way to
> do it:
>
> find . -type d | xargs chmod +t
>
> Then, I checked out a module from a repository as user A. Then, as user B,
> I did a 'svn up' in that WC, which failed because it couldn't chmod
> .svn/entries (as a result of the sticky bit being set?). This fails
> repeatedly. At this point, .svn/entries is still owned by user A.
>
> Then, as user A, attempt to 'svn up' in that WC. SVN will dutifully move
> .svn/tmp/entries over top of .svn/entries, but now .svn/entries will be
> owned by user B. User A can not update his WC.
>
> The only way that user A can regain control of his own WC is if user B does
> a 'svn up' in the WC which fails. Then, user A can successfully complete a
> 'svn up' because the permissions on .svn/entries have been switched back by
> user B (in combination with the sticky bit?).
>
> With the right combinations of 'svn up' commands between user A and B, they
> can manage to allow either one to have control of the repository but it's
> not entirely clear to me how they do this. They both cannot have control,
> though, and neither one can unilaterally gain control that I know of.
>
> Am I doing things right? Is there something else I might be missing?
>
> Thanks,
>
> Scott
>
>
> -----Original Message-----
> From: Branko Cibej brane-at-xbc.nu |Subversion/1.0-Allow|
> [mailto:q8cmhkv3bi0t@sneakemail.com] Sent: Tue 12/9/2003 6:29 PM
> To: Scott Wolford
> Cc: y2w2de9j001@sneakemail.com; users@subversion.tigris.org;
> dev@subversion.tigris.org Subject: Re: WC permissions
>
> Ryan Hunt wrote:
> > On Dec 9, 2003, at 12:15 PM, y2w2de9j001@sneakemail.com wrote:
> >> What are the fundamental problems with allowing more than two people
> >> from working within the same WC, other than that svn is chmod'ing
> >> files that it might not need to, then failing with EPERM?
> >>
> >> Thanks,
> >>
> >> Scott
> >
> > I would like to know this too as it is becoming more and more
> > essential that all users of my repository use the same WC. My full WC
> > is currently 200GB and scheduled to be 5TB within 6-9 months. This
> > will be impossible to maintain more than a couple of WCs.
> >
> > Is this going to be allowed in future versions, or does anyone have a
> > work around?
>
> 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.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Dec 10 01:41:55 2003

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

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