hi, gentoo comes with umask 0022. sharing repositories via unix group permission is common when using ssh+svn. however for multi user access to the svn rep subsequent db log files must be accessible by all users. umask 0022 doesn't fit in here. set umask to 0002. see http://svnbook.red-bean.com/svnbook/ch06s05.html suggestion: merge svn to svn-bin and install the wrapper from the url above as svn.
svn+ssh executes svnserve. this wrapper must also installed for this binary. well, it's not easy to do this per default.. probably a warning should be placed after emerge that svn's umask is altered.. or /etc/conf.d/svn file which is read by the wrapped to get the umask which should be set..
I feel that this can better be done by the administrator of the system that hosts subversion. Note that alternatively one could use either https (apache) or use a tool like stunnel for secure repository access.
Do you really call "renaming svn everytime and installing a wrapper" after every upgrade easy? I don't. To be honest, I'm pissed everytime I forgot about that thing, and a user comes up to me, telling me, his svn command cries "broken repository!". A wrapper is exactly the thing a distribution is responsible for. Rename svn to svn-bin, svn-serve to svn-serve-bin and install a wrapper like this #!/bin/bash . ~/.svn-umask exec ${0}-bin
That isn't a bad idea at all, to do it from sort of a profile... I was thinking of something like: [ $SVN_UMASK ] && umask $SVN_UMASK And optionally an appropriate /etc/env.d/ script And ... don't forget apache and svn, which should be umasked as well.
.profile is something which is associated with a login shell. People might place stuff in there, which would be inappropriate to source in an svn session. Well I don't place such stuff in there :) I don't mind.. creating .svn-mask serves just one purpose I know. If every little problem is remedied with a dot-file in $HOME, my home dir would be full of cruft.. Some people proposed an .env file, when they discussed if kde-startup should source .profile. They ended up sourcing .profile. Probably we should just do the same here, and let people put an "SVN_MASK = xy" in there.
The sanest solution to this is to create a path with your wrapper scripts that is loaded before /usr/bin for at least your sshd process. If you want to automate renaming I suggest you employ a hack in /etc/portage/bashrc. There are many different wrappers thinkable for subversion and these kind of wrappers by default have some security issues. A nice solution also comes to mind in using acl's. With acl's it is possible to set for a directory what the properties for created files need to be: "setfacl --recursive -m d:g::rwx /path/to/svn/repos"
autoconf, automake, ant, eclipse, firefox, mozilla, wine.. they all have one thing in common. Gentoo has wrapper scripts for them! (just do "grep gentoo /usr/bin/*") Gentoo does fix shortcomings of individual programs regularly. Do you really advices users of mozilla, ant, wine, etc.. to hack their sshd conf to get a "sane" solution? The umask problem is a well known problem to svn, even acknowledged by the official svn handbook. Without proper umasks a group-wise sharing of a svn+ssh acccessed svn-repo is _impossible_. The only security issue here is, that with Gentoo you are forced to share an account/password with other users, since otherwise you'll fall into the umask trap. So, got ahead and fix the shortcomings of svn by adding a wrapper script as the svn handbook advices. Paul, marking the bug RESOLVED will not fix it, even if you change it to WONTFIX again. Just because there is no obvious simple solution that does not mean that no good one can be found by working on it.
Using ACL's is a working and simple solution. As the documentation is lacking I'll give a short overview: - Compile your kernel with ACL support for your favourite filesystem - Set the ACL useflag - Ensure that you emerge the acl package - Mount your filesystem with the acl mount option (or possibly include user_xattr) - go to your svn root dir - execute "find -type d -exec setfacl -m d:g::rwx {} \;" - Now all files created in these directories are created with group write permissions
>Using ACL's is a working and simple solution. As the documentation is lacking > I'll give a short overview: > - Compile your kernel with ACL support for your favourite filesystem I'm subscribed to a virtual server. I'm getting a precompiled kernel. No ACL support for me. Further there are many situations where it's not possible to use ACL, beside that it just doesn't feel right to push something to the kernel which should be solved at user-space.
I've looked this over carefully and come to the conclusion that it's inappropriate for the Gentoo subversion ebuild to install wrapper scripts. First, Paul has good points regarding alternative methods to control the permissions on the repository. Second it's impossible to write a one-size-fits-all wrapper script for this; i.e. there's no way for us to know in Gentoo whether the system administrator will want user-controlled umasks as Clemens suggests in comment #3 or site-wide masks as Dick suggests in comment #4. Fourth, wrapping the svn program will also result in the umask applying to checked-out repositories in user home directories. Fifth, it's easy for the system administrator to install custom wrappers in /usr/local/bin where they won't be overwritten when subversion is updated. Clemens, you're right that marking this WONTFIX doesn't make the problem go away, but IMHO there is no way in the ebuild to make the problem go away. This is simply something that needs to be addressed either by the system administrator or by subversion upstream.
Well, ok. Do you know a package/system/whatever that let portage be patched automatically? Some kind of metaportage, where ebuilds are customized automatically, when esyncing. I haven't found something like that yet, but this problem can be solved by something like a metaportage system. At least I wouldn't have to edit the ebuild everytime.
What you try is to put a hack in /etc/portage/bashrc that performs the modifications for you.
*** Bug 71001 has been marked as a duplicate of this bug. ***
Why not put in a modification to the ebuild that's controlled by a local USE switch? The solution mentioned by the reporter is standard enough that the authors of Subversion itself talk about it extensively in the SVN book, which seems to imply to me that they at least consider it the correct solution to this sort of problem.
*** Bug 94894 has been marked as a duplicate of this bug. ***
