Bug 6113

Summary: Wrong umask
Product: Sisyphus Reporter: Mikhail Yakshin <greycat>
Component: subversionAssignee: Sviatoslav Sviridov <svd>
Status: CLOSED FIXED QA Contact: qa-sisyphus
Severity: normal    
Priority: P2 CC: cas, ender, shrek
Version: unstable   
Hardware: all   
OS: Linux   

Description Mikhail Yakshin 2005-02-13 02:35:37 MSK 
/usr/bin/svnserve запускается с umask по умолчанию, то есть обычно с 0022, что
есть неправильно. При использовании их по протоколу svn+ssh он орудует файлами в
директории /var/lib/subversion, где надо иметь возможность сохранять группы у
файлов, как есть, а не делать каждый раз группу у файла равной основной группе
пользователя.

Для этого везде рекомендуется оборачивать svnserve скриптиком, примерно такого
содержания:

$ cat /usr/bin/svnserve
#!/bin/bash
umask 002; /usr/bin/svnserve.real $@

где /usr/bin/svnserve.real - бинарник, который сейчас в пакете называется
/usr/bin/svnserve

При активной работе с несколькими человеками над одним проектом в svn, это
становится очень актуальным.

Дополнительная информация о проблеме доступна легко в google, скажем, по
ключевым словам "subversion umask"
Comment 1 Sviatoslav Sviridov 2005-02-13 13:19:38 MSK 
Достаточно ли сделать враппер только для svnserve, или для svn, svnlook,
svnadmin тоже желательно сделать?

ЗЫ как, например, предлагается здесь:
http://svn.haxx.se/users/archive-2004-10/0745.shtml
Comment 2 Sviatoslav Sviridov 2005-02-28 12:54:56 MSK 
Fixed in subversion-1.1.3-alt1
Comment 3 Dmitry V. Levin 2005-11-25 02:38:58 MSK 
Да, в svn-book из пакета subversion-doc, а именно в разделе "Supporting Multiple
Repository Access Methods" есть рекомендация устанавливать umask 0002 для svn,
svnadmin, svnlook и svnserve.
Не понимаю, если это действительно нужно, то почему они не сделали это прямо в
самих утилитах?
Comment 4 Mikhail Yakshin 2005-11-26 12:24:37 MSK 
Это нужно только при некотором относительно хитром способе доступа к
репозиторию. Более традиционным считается доступ через WebDAV (на apache2), но
из-за того, что у нас и с тем, и с другим довольно проблематично - используется
просто svn-over-ssh, с которым вылезают вот такие вот проблемы.