una - Evite que subversion modifique los permisos de archivos de Linux.

permisos linux 777

Question

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 que el Owner y el Group establezcan en los archivos httpd.conf , y todos los directorios dentro de documentRoot reciban permisos de 700, todos los archivos no ejecutables (por ej. * .Php, * .smarty, * .png) reciban 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 en apache:apache para que el servicio httpd los lea, ya que solo el propietario del archivo tiene acceso mediante los permisos.

Cada vez que ejecuto una 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 de los archivos se configuran en algo diferente de lo que eran originalmente (es decir, un archivo .htm antes de que una actualización sea 600, pero después y svn update , se establece en 755, o incluso en 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).

Answer 1

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

Answer 2

Puede almacenar propiedades en un archivo en Subversion (vea 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.

Answer 3

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

Puede 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.

Answer 4

Una cosa que puede considerar es instalar el binario svn fuera de su ruta y colocar un script de reemplazo (en y llamado /usr/bin/svn , o lo que sea) en la ruta. 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.

Answer 5

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.

Answer 6

Puedes resolver esto . Use setgid

1. Tienes apache:apache ejecuta el servidor

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

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

   Ejemplo (''2'' es setgid):

   chmod 2750

4. Haz que apache el grupo de todos los directorios

Lo que ocurre es

• Los nuevos archivos y directorios creados por cualquier cuenta serán propiedad del grupo apache

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

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