Pregunta Evite que subversion modifique los permisos de archivos de Linux.


Toda mi base de código se almacena en un repositorio de subversión que disperso entre mis servidores web Apache con equilibrio de carga, por lo que es fácil consultar el código, ejecutar actualizaciones y obtener sin problemas mi código en desarrollo en producción.

Uno de los inconvenientes de los que estoy seguro es que es fácil trabajar (aparte de ejecutar un script en cada proceso de finalización), es obtener los permisos de Linux configurados (volver) en los archivos que se actualizan o se desprotegen con subversión. Nuestro equipo de seguridad lo tiene configurado para Owner y Group establecer en el httpd.conf archivos, y todos los directorios dentro del documentRoot recibe permisos de 700, todos los archivos no ejecutables (por ejemplo, * .php, * .smarty, * .png) reciben permisos de Linux de 600, todos los archivos ejecutables reciben 700 (por ejemplo, * .sh, * .pl, * .py). Todos los archivos deben tener el propietario y grupo configurados para apache:apache para que el servicio httpd lo lea, ya que solo el propietario del archivo está configurado para tener acceso a través de los permisos.

Cada vez que ejecuto un svn update, o svn co, aunque los archivos no se pueden crear (es decir svn update), Descubro que la propiedad de los archivos se establece en la cuenta que ejecuta los comandos svn, y muchas veces, los permisos del archivo se establecen en algo distinto de lo que eran originalmente (es decir, un archivo .htm antes) una actualización es 600, pero después y svn update, se establece en 755, o incluso 777).

¿Cuál es la forma más fácil de evitar los intentos de subversión de actualizar los permisos y la propiedad del archivo? ¿Hay algo que se pueda hacer dentro del cliente svn o en el servidor Linux para conservar los permisos del archivo original? Estoy ejecutando RHEL5 (y ahora 6 en algunas instancias seleccionadas).


32
2018-05-10 16:20


origen


Respuestas:


el propietario de los archivos se configurará para el usuario que ejecuta el comando svn debido a la forma en que implementa el comando subyacente: elimina y reemplaza los archivos que se actualizan, lo que hará que la propiedad 'cambie' al usuario correspondiente. La única manera de evitar esto es realizar el svn como el usuario del que se supone que los archivos son propiedad. Si desea asegurarse de que son propiedad de un usuario en particular, ejecute el comando como ese usuario.

Con respecto a los permisos, svn solo obedece a la configuración umask de la cuenta, probablemente sea algo así como 066, para asegurarse de que el archivo no sea accesible al grupo y a otras cuentas, debe emitir 'umask 077' antes de realizar el svn. arriba, esto asegura que los archivos solo son accesibles para la cuenta de usuario que emite el comando.

Prestaría atención al problema de seguridad de implementar los datos de subversión en el servidor web a menos que los directorios .svn estén seguros.


16
2018-05-10 16:41



Puede almacenar propiedades en un archivo en Subversion (ver http://svnbook.red-bean.com/en/1.0/ch07s02.html) Está especialmente interesado en la propiedad svn: ejecutable, que se asegurará de que se almacena el permiso ejecutable.

Sin embargo, no hay una forma general de hacer esto para todos los permisos. Subversion tampoco almacena propiedad: supone que, si verifica algo, es su propietario.


9
2018-05-10 16:25



Una cosa que puede considerar hacer es instalar el svn binario fuera de tu ruta, y poniendo un script de reemplazo (en y llamado /usr/bin/svn, o lo que sea) en el camino. El script se vería así:

#!/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

Una desventaja definitiva es que probablemente tendrá que hacer una cierta cantidad de análisis de los argumentos pasados ​​a svn, es decir, puede pasar la misma ruta a su chmod, no ejecutar chmod para la mayoría de los comandos de svn, etc.

También hay probablemente algunas consideraciones de seguridad aquí. No sé cómo es su entorno de despliegue, pero probablemente debería investigar eso un poco más.


1
2018-03-21 18:43



Escribí un pequeño script que almacena los permisos y el propietario, ejecuta su comando SVN y restaura los permisos y el propietario. Probablemente no sea a prueba de piratas informáticos, pero para uso privado hace el trabajo.

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
2017-08-05 09:00



Puedes resolver esto. Utilizar setgid.

  1. Tienes apache:apache corriendo el servidor

  2. Establezca permisos de grupo en todos los archivos y directorios. El servidor leerá los archivos por su grupo

  3. Conjunto setgid en todos los directorios, solo en los directorios: configurar esto en archivos tiene una función diferente

    Ejemplo ('2' es setgid):

    chmod 2750

  4. Hacer apache el grupo de todos los directorios

Lo que ocurre es

  • Nuevos archivos y directorios creados por cualquier cuenta será propiedad de la apache grupo

  • Los nuevos directorios heredarán setgid y así preservar la estructura sin ningún esfuerzo

Ver https://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories


1
2018-03-15 02:59



También tuve un problema similar. Encontré un guión genial: asvn (SVN de archivo).

Puedes descargarlo aquí: 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.

Esta entrada de blog (que me ayuda a encontrar guiones) http://jon.netdork.net/2010/06/28/configuration-management-part-ii-setting-up-svn/ muestra un uso simple


0
2018-06-25 01:32