Избегайте использования Subversion для изменения прав доступа к файлам Linux. - PullRequest
Новая
       7

Избегайте использования Subversion для изменения прав доступа к файлам Linux.

32 голосов
/ 10 мая 2011

Вся моя кодовая база хранится в репозитории subversion, который я распределяю среди своих веб-серверов Apache с балансировкой нагрузки, что позволяет легко проверять код, запускать обновления и беспрепятственно переносить мой код в процессе разработки на производство.

Одно из неудобств, которое, я уверен, легко обойти (кроме выполнения сценария при каждой проверке), заключается в получении заданных (возвращаемых) разрешений Linux для файлов, которые обновляются или извлекаются с помощью subversion. Наша команда безопасности установила, что Owner и Group установлены в файлах httpd.conf , и все каталоги в пределах documentRoot получают разрешения 700, все неисполняемые файлы (например, * .php, * .smarty, * .png) получают разрешения Linux на 600, все исполняемые файлы получают 700 (например, * .sh, * .pl, * .py). Все файлы должны иметь владельца и группу, настроенные на apache:apache, чтобы они могли быть прочитаны службой httpd, поскольку только владелец файла должен иметь доступ через разрешения.

Каждый раз, когда я запускаю svn update или svn co, даже если файлы не могут быть созданы (например, svn update), я обнаруживаю, что право собственности на файлы устанавливается для учетной записи, которая при выполнении команд svn, и часто, права доступа к файлу устанавливаются не так, как они были изначально (например, файл .htm до обновления 600, но после и svn update он устанавливается на 755, или даже 777).

Какой самый простой способ обойти попытки Subversion обновить права доступа к файлу и владельца? Есть ли что-то, что можно сделать в клиенте svn или на сервере Linux, чтобы сохранить исходные права доступа к файлу? Я использую RHEL5 (и теперь 6 на нескольких выбранных экземплярах).

Ответы [ 6 ]

16 голосов
/ 10 мая 2011

владельцем файлов будет назначен пользователь, который запускает команду svn из-за того, как он реализует базовую команду up - он удаляет и заменяет файлы, которые обновляются, что приведет к «смене» владельца на соответствующий пользователь. Единственный способ предотвратить это - фактически выполнить svn как пользователь, которому должны принадлежать файлы. Если вы хотите убедиться, что они принадлежат определенному пользователю, выполните команду от имени этого пользователя.

Что касается разрешений, svn только подчиняется настройкам umask учетной записи - это, вероятно, что-то вроде 066 - чтобы гарантировать, что файл недоступен для групповых и других учетных записей, вам нужно выполнить umask 077 перед выполняя команду svn up, это гарантирует, что файлы доступны только учетной записи пользователя, выполняющей команду.

Я бы обратил внимание на проблему безопасности при развертывании данных Subversion на веб-сервере, если только каталоги .svn не защищены.

9 голосов
/ 10 мая 2011

Вы можете сохранить свойства файла в Subversion (см. http://svnbook.red -bean.com / ru / 1.0 / ch07s02.html ). Вы особенно заинтересованы в свойстве svn: исполняемый файл, который будет гарантировать, что разрешение исполняемого файла хранится.

Хотя нет общего способа сделать это для всех разрешений. Subversion также не хранит права собственности - она ​​предполагает, что, если вы что-то проверите, вы им владеете.

1 голос
/ 15 марта 2017

Вы можете решить это .Используйте setgid.

  1. У вас apache:apache работает сервер

  2. Установите групповые разрешения для всех файлов и каталогов.Сервер будет читать файлы по его группе

  3. Установить setgid во всех каталогах - только для каталогов: установка этого параметра для файлов имеет другую функцию

    Пример ('2' - setgid):

    chmod 2750

  4. Сделать apache группой всех каталогов

Что происходит,

  • Новые файлы и каталоги, созданные любой учетной записью , будут принадлежать группе apache

  • Новые каталоги будут наследовать setgid и, таким образом, сохранять структуру без каких-либо усилий

См. https://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories

1 голос
/ 05 августа 2015

Я написал небольшой скрипт, который хранит разрешения и владельца, выполняет вашу команду SVN и восстанавливает права доступа и владельца.Вероятно, он не защищен от хакерских атак, но для частного использования он делает свою работу.

svnupdate.sh: 

#!/usr/bin/env bash
if [ $# -eq 0 ]; then
    echo "Syntax: $0 <filename>"
    exit
fi

IGNORENEXT=0
COMMANDS=''
FILES='';
for FILENAME in "$@"
do
    if [[ $IGNORENEXT > 0 ]]; then
        IGNORENEXT=0
    else
        case $FILENAME in
            # global, shift argument if needed
            --username|--password|--config-dir|--config-option)
            IGNORENEXT=1
            ;;
            --no-auth-cache|--non-interactive|--trust-server-cert)
            ;;
            # update arguments, shift argument if needed
            -r|--revision|--depth|--set-depth|--diff3-cmd|--changelist|--editor-cmd|--accept)
            IGNORENEXT=1
            ;;
            -N|--non-recursive|-q|--quiet|--force|--ignore-externals)
            ;;
            *)
            if [ -f $FILENAME ]; then
                FILES="$FILES $FILENAME"
                OLDPERM=$(stat -c%a $FILENAME)
                OLDOWNER=$(stat -c%U $FILENAME)
                OLDGROUP=$(stat -c%G $FILENAME)
                FILECOMMANDS="chmod $OLDPERM $FILENAME; chown $OLDOWNER.$OLDGROUP $FILENAME;"
                COMMANDS="$COMMANDS $FILECOMMANDS"
                echo "COMMANDS: $FILECOMMANDS"
            else
                echo "File not found: $FILENAME"
            fi
            ;;
        esac
    fi
done
OUTPUT=$(svn update "$@")
echo "$OUTPUT"
if [[ ( $? -eq 0 ) && ( $OUTPUT != Skipped* ) && ( $OUTPUT != "At revision"* ) ]]; then
    bash -c "$COMMANDS"
    ls -l $FILES
fi
1 голос
/ 21 марта 2012

Одна вещь, которую вы можете рассмотреть, - это установить бинарный файл svn вне вашего пути и поместить в него заменяющий скрипт (в и с именем /usr/bin/svn или как угодно).Сценарий будет выглядеть примерно так: 

#!/bin/sh

# set umask, whatever else you need to do before svn commands

/opt/svn/svn $* # pass all arguments to the actual svn binary, stored outside the PATH

# run chmod, whatever else you need to do after svn commands

Определенным недостатком является то, что вам, вероятно, придется выполнить некоторое количество анализа аргументов, передаваемых в svn, то есть вы можете передать тот же путь к вашемуchmod, не запускать chmod для большинства команд svn и т. д.

Здесь также, вероятно, есть некоторые соображения безопасности.Я не знаю, на что похожа ваша среда развертывания, но вам, вероятно, стоит изучить это немного дальше.

0 голосов
/ 25 июня 2016

У меня тоже была похожая проблема. Я нашел классный скрипт: asvn (Архив SVN).

Вы можете скачать его здесь: https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/asvn

Description:
Archive SVN (asvn) will allow the recording of file types not
normally handled by svn. Currently this includes devices,
symlinks and file ownership/permissions.

Every file and directory has a 'file:permissions' property set and
every directory has a 'dir:devices' and 'dir:symlinks' for
recording the extra information.

Run this script instead of svn with the normal svn arguments.

Эта запись в блоге (которая помогает мне найти сценарий) http://jon.netdork.net/2010/06/28/configuration-management-part-ii-setting-up-svn/ показывает простое использование.

...