Re: [Savannah-hackers-public] Re: savannah shell access?

[Jim Meyering]

Sylvain Beucler <address@hidden> wrote:
...
>>From a security pov, there's a place where people need to put their
> files so that other projects/hooks cannot alter them. So I think the
> working directories (at least the top-level directory) need to be
> pre-created.
>
> FHS doesn't garantee that files in /var/tmp so following this view
> this means pre-created dirs need to be placed in /var/lib.
>
>
> Thus /var/lib/git/cvs-to-git/ and /var/lib/git/cvs-to-git/projectname
> would need to be created at project creation time.

I'll be happy to move things to
  /var/lib/git/git-to-cvs
once things are settled -- or wherever else seems appropriate.

I am not too worried about people damaging these cvs-checked-out
working directories, because the worst that can result is that the
cvs mirror will not be up to date.  And I presume that can be fixed
manually, probably by running git-cvsexportcommit for each missed
change set, once the underlying failure has been fixed.

I was careful to make the working directory set-gid to the project group.

> Maybe this security is too tight and cumbersome. If there's no risk
> when a project messes another project's working copy or pre-creates it
> with different permissions, then we can use something like /var/lock
> (1777) and let the hook create git-to-cvs/ and git-to-cvs/project on
> the fly when missing. In which case /var/tmp would be a good location.
>
>
> That's the 2 solutions I see. Do you think there's a risk with the
> first one? Since this can be a reusable setup, assume users may have
> local access.

One small measure that may help avoid casual or inadvertent
interference: leave each working directory "chmod 0", and have
the git update hook do "chmod 755 ...", do its job, then "chmod 0"
to re-protect it.