Evite que subversion modifique los permisos de archivos de Linux.

Question

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

Uno de los inconvenientes que estoy seguro de que hay una solución fácil (aparte de ejecutar un script en cada finalización), es obtener los permisos de Linux establecidos (volver) en los archivos que se actualizan o eliminan con subversión . Nuestro equipo de seguridad lo ha establecido como Owner y Group en los archivos httpd.conf, y todos los directorios dentro de documentRoot reciben 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 el grupo establecidos 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 ejecute un svn update, o svn co, a pesar de que los archivos no se pueden crear (es decir svn update), me estoy encontrando que la propiedad de los archivos se está ajustado a la cuenta que ejecuta los comandos SVN, y muchas veces, los permisos de los archivos se establecen en algo distinto 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 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

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' a el usuario relevante. 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 asegurar que el archivo no sea accesible al grupo y otras cuentas, debe emitir 'umask 077' antes de realizar el svn up, esto garantiza que los archivos solo sean accesibles para la cuenta del usuario que emite el comando.

Me gustaría prestar 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 2

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

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

Answer 3

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 guión sería algo como esto:

#!/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 clara es que es probable que tenga que hacer una cierta cantidad de análisis de los argumentos que se pasan a SVN, es decir,para que pueda pasar la misma ruta a su chmod, no ejecutar chmod para la mayoría de los comandos svn, etc.

También es probable que haya 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 4

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 es a prueba de hackers, 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 5

Yo también tenía un problema similar. Encontré una buena secuencia de comandos: 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 script) http://jon.netdork.net/2010/06/28/configuration-management-part-ii-setting-up-svn/ muestra un uso simple.

Answer 6

Puede resolver este. Use setgid.

1. Usted tiene apache:apache que ejecuta el servidor

2. permiso de grupo en TODOS los archivos y directorios. El servidor leerá archivos por su grupo

3. Conjunto setgid en todos los directorios - sólo en directorios: configurándolo en archivos tiene una función diferente

   Ejemplo ('2' es setgid):

   chmod 2750

4. Hacer apache el grupo de todos los directorios

Lo que pasa es

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

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

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