You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Da...@mckinsey.com on 2006/02/24 15:02:48 UTC
shared local working copy unix
I hope this isn't an oft repeated questions I've searched and found some
stuff but not really enough to settle my concerns. I've a server with
limited disk space and a large amount of files in a repository that
various users need to work on. As such I've created a single working copy
on the server for them to use and have also been asked to write a shell
scripts that will get the files to a users workspace (essentially their
home directory), move/add the files into the working copy when they are
done and to add the files to the remote repository (This is kinda stupid
but I couldn't really talk them out of it). This is all on a AIX unix
box.
There are --I don't think surprisingly-- file permission problems and I'm
wondering the best approach to this. What I've done is to require all
users to be part of the same group that owns the local working copy, I've
set the sticky bit on the directories to that group. In my shell scripts
I've set umask to 002 and am copying existing files to the working copy
and doing chmod=+rw.
My questions are:
Would it be wiser to set up the shell scripts to run as suid of the actual
owner of the local working copy?
Subversion doesn't seem to notice acl changes on a file is this by design
and why?
Is my approach completly borked and if so is there a better one?
Regards,
David Peterka
(212) 415-1774
+=========================================================+
This message may contain confidential and/or privileged
information. If you are not the addressee or authorized to
receive this for the addressee, you must not use, copy,
disclose or take any action based on this message or any
information herein. If you have received this message in
error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation.
+=========================================================+
Re: shared local working copy unix
Posted by Da...@mckinsey.com.
Thanks for the thoughts, I've made the arguement for new disk and all that
but it's their stuff and their $ and it's an olde aix mainframe style
thing for which disk isn't exactly cheap.
Before I started writing the scripts I had done the googling and found bug
trackers about shared working copies and references to that bit of
functionality. (ref this one about security probs
http://64.233.179.104/search?q=cache:1rolld_TQQAJ:www.contactor.se/~dast/svn/archive-2004-04/0522.shtml+subversion+shared+working+copy&hl=en&gl=us&ct=clnk&cd=4&client=firefox-a)
What I couldn't find is a suggested approach approach for planning around
it. So the use case is a few users need to use the shared working copy,
likely hood of them editing something at the same time is low but I've
also added a lock to the script we're using (also a requested feature) to
prevent this. It's correct that suid can't be used in the shell
environment I'm using it would have to be done with a bit of c, rather
avoid that anyways. I realize that this is probably not the best way to
do things but in the end sounds like it's doable, just not the greatest
approach.
Regards,
David Peterka
(212) 415-1774
Theo Van Dinter <fe...@kluge.net>
02/24/2006 11:41 AM
To
cc
Subject
Re: shared local working copy unix
On Fri, Feb 24, 2006 at 11:00:50AM -0500, Phillip Susi wrote:
> You really can't share a wc between multiple users. Obviously they can
> try to edit the same file and clobber each other, and when they do go to
> do a commit to the repository, the repository won't know who actually
> did the commit. Also if two people try to commit, update, revert, or
> whatever at the same time, you're going to clobber the wc.
Well, you can, but it all depends on what the use pattern is. An example
is that for a project I'm working on, we have a WC of the website as the
docroot on the webserver. Anyone related to the project can go in and
make changes to the WC and commit from there. This isn't a huge issue
because there are only 4-8 people who could make changes, and we do
so very rarely (the website isn't the product we're working on), so we
don't worry about the issues of multiple people editing the same file,
different operations running at the same time, etc.
In the end, my opinion is that if there's going to be any form of
complexity wrt how people do their work, there should be separate WC
per user. Disk is cheap. :)
BTW: "the repository won't know who actually did the commit" -- sure it
will, assuming the users don't su/sudo to run the commands. It read as if
they are simply sharing the WC via group/permissions as opposed to having
a
"group user" that people switch to so they can make edits.
> IIRC, shell scripts can not be suid, only binaries can.
It depends on the OS actually.
--
Randomly Generated Tagline:
"Depends on how you define 'always'. :-)" - Larry Wall
[attachment "attnzpxe.dat" deleted by David
Peterka/NYC/NorthAmerica/MCKINSEY]
+=========================================================+
This message may contain confidential and/or privileged
information. If you are not the addressee or authorized to
receive this for the addressee, you must not use, copy,
disclose or take any action based on this message or any
information herein. If you have received this message in
error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation.
+=========================================================+
Re: shared local working copy unix
Posted by Theo Van Dinter <fe...@kluge.net>.
On Fri, Feb 24, 2006 at 11:00:50AM -0500, Phillip Susi wrote:
> You really can't share a wc between multiple users. Obviously they can
> try to edit the same file and clobber each other, and when they do go to
> do a commit to the repository, the repository won't know who actually
> did the commit. Also if two people try to commit, update, revert, or
> whatever at the same time, you're going to clobber the wc.
Well, you can, but it all depends on what the use pattern is. An example
is that for a project I'm working on, we have a WC of the website as the
docroot on the webserver. Anyone related to the project can go in and
make changes to the WC and commit from there. This isn't a huge issue
because there are only 4-8 people who could make changes, and we do
so very rarely (the website isn't the product we're working on), so we
don't worry about the issues of multiple people editing the same file,
different operations running at the same time, etc.
In the end, my opinion is that if there's going to be any form of
complexity wrt how people do their work, there should be separate WC
per user. Disk is cheap. :)
BTW: "the repository won't know who actually did the commit" -- sure it
will, assuming the users don't su/sudo to run the commands. It read as if
they are simply sharing the WC via group/permissions as opposed to having a
"group user" that people switch to so they can make edits.
> IIRC, shell scripts can not be suid, only binaries can.
It depends on the OS actually.
--
Randomly Generated Tagline:
"Depends on how you define 'always'. :-)" - Larry Wall
Re: shared local working copy unix
Posted by Phillip Susi <ps...@cfl.rr.com>.
David_Peterka@mckinsey.com wrote:
> I hope this isn't an oft repeated questions I've searched and found some
> stuff but not really enough to settle my concerns. I've a server with
> limited disk space and a large amount of files in a repository that
> various users need to work on. As such I've created a single working copy
> on the server for them to use and have also been asked to write a shell
> scripts that will get the files to a users workspace (essentially their
> home directory), move/add the files into the working copy when they are
> done and to add the files to the remote repository (This is kinda stupid
> but I couldn't really talk them out of it). This is all on a AIX unix
> box.
>
You really can't share a wc between multiple users. Obviously they can
try to edit the same file and clobber each other, and when they do go to
do a commit to the repository, the repository won't know who actually
did the commit. Also if two people try to commit, update, revert, or
whatever at the same time, you're going to clobber the wc.
> There are --I don't think surprisingly-- file permission problems and I'm
> wondering the best approach to this. What I've done is to require all
> users to be part of the same group that owns the local working copy, I've
> set the sticky bit on the directories to that group. In my shell scripts
> I've set umask to 002 and am copying existing files to the working copy
> and doing chmod=+rw.
>
> My questions are:
> Would it be wiser to set up the shell scripts to run as suid of the actual
> owner of the local working copy?
IIRC, shell scripts can not be suid, only binaries can.
> Subversion doesn't seem to notice acl changes on a file is this by design
> and why?
> Is my approach completly borked and if so is there a better one?
>
Yes, it is completely borked. The better way is to buy some more disks
( they are dirt cheap these days ) and give each user their own wc.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org