Bug 6113 - Wrong umask
: Wrong umask
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/subversion)
: unstable
: all Linux
: P2 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2005-02-13 02:35 by
Modified: 2005-11-26 12:24 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-02-13 02:35:37
/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 From 2005-02-13 13:19:38 -------
Достаточно ли сделать враппер только для svnserve, или для svn, svnlook,
svnadmin тоже желательно сделать?

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