>
>
> > From: Les Mikesell [mailto:lesmikesell_at_gmail.com]
> > Sent: 11 June 2008 14:01
> > To: Giulio Troccoli
> > Cc: users_at_subversion.tigris.org
> > Subject: Re: File permission after update
> >
> > Giulio Troccoli wrote:
> > > We use Subversion 1.4.4 on a Linux box with Apache. The user/group
> that
> > > runs apache is svn/svn, and umask for user svn is 000. We use a
> common
> > > WC to perform automatic merges. This WC is created once and then
> updated
> > > after every commit (in the post-commit hook)
> > >
> > > When I checked out the WC everything was fine: all files have rw
> > > permission for everybody and all directories have rwx permission
for
> > > everybody.
> > >
> > > When I do an update however, and I have new directories, these are
> added
> > > with rwx permission for svn user only, and r permission for the
> group
> > > and everybody else. This is particularly true for the .svn
> directories
> > > too.
> > >
> > > The problem we're having is that when a user then tries to merge
his
> > > changes, the script they use makes use of the WC and then commits
> from
> > > there. However Subversion complains that it cannot access a ./lock
> file
> > > and the commit fails.
> > >
> > > I'm sorry I cannot provide a more precise explanation, but we had
to
> fix
> > > the problem straight away (which means a simple chmod) to allow
the
> > > process to go through. Next time it happens I will make an effort
> and
> > > get more info.
> > >
> > > In the meantime, does anybody have any idea why this would happen?
> Has
> > > anybody experience something like this or similar?
> >
> > Subversion isn't designed to have a shared working copy. The best
fix
> > is to have a working copy for each user which will permit concurrent
> > work. The particular problem you are having is most likely being
> caused
> > by new files taking the primary group of the logged in user and
> > permissions based on his umask. You can fix that, but it's not the
> > right fix for this situation.
>
> I know that a shared WC is a bad idea. However, this is used for
merging
> purposes only, and the merging is done by a script. So it's a very
> controlled process. That doesn't make it right, I know.
>
> I forgot to say, sorry, that the user and group of the new
> files/directories is correctly svn/svn (the user/group apache runs
as).
> I thought about changing the user/group for apache to svn/users, as
> users is the group for all users, but I don't think that that would
make
> any difference and the permissions are correct only for the user svn,
> not for the group.
>
> Finally, the umask for all users is 002, so if Subversion used this to
> set the permission I should have had the correct ones for the group
too,
> which I didn't.
>
> Giulio
To make it even clearer
This is the user that runs Apache
ln1sub01 svn> id
uid=710(svn) gid=101(svn) groups=100(users),101(svn)
ln1sub01 svn> umask
000
This is the user who committed
ln1sub01 ln1sub01> id
uid=727(svn_gt) gid=101(svn) groups=100(users),101(svn)
ln1sub01 ln1sub01> umask
000
As you can see the umask is 000 for both. However, after the post-commit
has update the shared working copy
-rwxr-xr-x 1 svn svn 699 Jun 12 15:37 spasswd
THIS is my problem. Root's umask is 0022 so even if for some bizarre
reason SVN was using root's umask this would still be wrong.
Does anybody have an idea why Subversion is not using the umask
correctly? Or can anybody explain me how to use the umask with
Subversion? Or alternatively how to set Subversion to set the permission
as I want them?
Thanks
Giulio
Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851 VAT Reg No 778499447
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-12 16:49:09 CEST