Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via or IRC
Bug 48809 - subversion umask wrappers
Summary: subversion umask wrappers
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Paul de Vrieze (RETIRED)
: 71001 94894 (view as bug list)
Depends on:
Reported: 2004-04-23 11:59 UTC by Clemens Fruhwirth
Modified: 2005-06-03 12:48 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Clemens Fruhwirth 2004-04-23 11:59:34 UTC

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

suggestion: merge svn to svn-bin and install the wrapper from the url above as svn.
Comment 1 Clemens Fruhwirth 2004-04-26 09:43:25 UTC
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..
Comment 2 Paul de Vrieze (RETIRED) gentoo-dev 2004-06-07 04:43:36 UTC
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.
Comment 3 Clemens Fruhwirth 2004-10-07 14:15:47 UTC
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

. ~/.svn-umask
exec ${0}-bin
Comment 4 Dick Marinus 2004-10-07 14:43:40 UTC
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.
Comment 5 Clemens Fruhwirth 2004-10-07 15:07:31 UTC
.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.
Comment 6 Paul de Vrieze (RETIRED) gentoo-dev 2004-10-08 05:43:50 UTC
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"
Comment 7 Clemens Fruhwirth 2004-10-09 07:40:46 UTC
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.
Comment 8 Paul de Vrieze (RETIRED) gentoo-dev 2004-10-09 10:43:06 UTC
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
- 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
Comment 9 Clemens Fruhwirth 2004-10-09 11:29:19 UTC

>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.
Comment 10 Aron Griffis (RETIRED) gentoo-dev 2004-11-11 19:10:05 UTC
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.
Comment 11 Clemens Fruhwirth 2004-11-12 00:13:07 UTC
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.
Comment 12 Paul de Vrieze (RETIRED) gentoo-dev 2004-11-13 07:39:13 UTC
What you try is to put a hack in /etc/portage/bashrc that performs the modifications for you.
Comment 13 Aron Griffis (RETIRED) gentoo-dev 2004-11-13 11:49:08 UTC
*** Bug 71001 has been marked as a duplicate of this bug. ***
Comment 14 Tyler Berry 2004-11-13 13:13:17 UTC
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.
Comment 15 Paul de Vrieze (RETIRED) gentoo-dev 2005-06-03 12:48:06 UTC
*** Bug 94894 has been marked as a duplicate of this bug. ***