Subversion sudo svn update cambia la propiedad del file y rwx

Estoy limitando los permissions en un determinado file, settings.py en mi directory svn-linked para que solo pueda ser leído por los usuarios sudo y apache, que va con el nombre de usuario, www-data . Por lo tanto, en settings.py, configuré sudo chmod 640 settings.py y sudo chown www-data:www-data settings.py . Todavía quiero que mis usuarios no privilegiados puedan svn update y svn commit , así que con sudo visudo , he establecido

 unprivileged_user ALL = /usr/bin/svn commit *, /usr/bin/svn update *, \ /usr/bin/svn update 

para que este usuario todavía pueda hacer sudo svn commit y sudo svn update . No podrá hacer svn commit o svn update simples debido a los permissions limitados en settings.py . Si el usuario sin privilegios intenta hacer eso, habrá un post de svn que dice que la copy de trabajo está bloqueada. Sin embargo, he notado que cuando sudo svn update , el usuario sin privilegios se actualiza como root y, como resultado, el file que se actualiza desde el repository svn ahora es propiedad de root:root con 644 privilegios. Esto va en contra de lo que trato de hacer con settings.py propiedad de www-data:www-data . ¿Qué puedo hacer para que www-data sea ​​siempre el propietario y los pricipios rwx sigan siendo los mismos?

El usuario de www-data tendrá un UID diferente en cada sistema en el que se encuentre, lo que lo convertirá efectivamente en un nuevo usuario en cada sistema. No puede pnetworkingecir qué usuario será, por lo que no puede configurar al propietario de forma adecuada. Quien lo revise será el dueño.

Además, svn no rastrea los permissions. Solo rastrea si un file es ejecutable o no. Los permissions con los que viene el file vienen determinados por umask.

Use una secuencia de commands que realice la actualización y restablezca el permiso.

svnupdate.sh:

 #!/bin/bash MY_PROJ_PATH=/home/.... # Put you path here pushd $MY_PROJ_PATH svn update $* && chown -R www-data. . && chmod 640 settings.py popd 

también asegúrese de que chmod 750 /usr/local/bin/svnupdate.sh para evitar problemas de security en el command sudo y también actualice los files sudoeres:

 unprivileged_user ALL = /usr/bin/svn commit *, /usr/local/bin/svnupdate.sh 

Esto es lo que tengo ahora. Estoy usando un enlace de actualización de svn de publicación, y no sé qué tan seguro es. Esto es solo para la svn update . Por favor, siéntase libre de express sus opiniones sobre esto.

En usr/local/bin , creo ssh-action.sh basado en esto: http://top-frog.com/2009/04/23/client-side-pre-and-post-svn-hooks-with -unix-alias /

Mi real ssh-action.sh ve así:

 #!/bin/bash REAL_SVN='/usr/bin/svn'; BASE_PATH='/home/unprivileged_user/test_svn/'; $REAL_SVN $@; wait; # post-svn actions if [ $1 = 'up' ] || [ $1 = 'update' ]; then find -L $BASE_PATH -type f -name 'settings.py' -exec bash -c 'sudo chmod 0400 $0 && sudo chown www-data $0; sudo chgrp www-data $0' '{}' \; fi 

Luego, en sudo visudo , agrego esto a la parte inferior:

 unprivileged_user ALL = NOPASSWD: /bin/chown www-data */test_svn/settings.py, /bin/chmod 0400 */test_svn/settings.py, /bin/chgrp www-data */test_svn/settings.py 

A continuación, cd /home/unprivileged_user , abra .bashrc y añádalo al final:

 alias svn = /usr/local/bin/ssh-action.sh 

Después, tengo que hacer que .bashrc inmutable para que los desfavorecidos no puedan editarlo para eludir mi enlace svn. Lo hago con sudo chattr +i .bashrc

Con esto, con suerte, siempre que el test_svn privilegios intente svn update la copy de trabajo test_svn , settings.py será propiedad de www-data:www-data con 400 permissions. ¿Qué piensan ustedes? ¿Hay algún defecto de security aquí? Gracias.