Posterior a mirar en diversos repositorios y páginas webs finalmente nos hemos encontrado la respuesta que te mostramos aquí.
Solución:
Si entiendo bien su pregunta, su problema comienza con la estructura del marco de permisos / usuarios de Linux. Por lo tanto, el usuario propietario del proceso Apache es el que crea directorios y archivos cuando ejecuta su script.
Si necesita separación de usuarios para los scripts, por ejemplo: tiene diferentes directorios para diferentes hosts (virtuales) en su servidor y no desea que el script de un host actúe sobre los datos de un host diferente en el mismo servidor (apache), entonces debería usar ‘mpm_itk_module’ en lugar del apache ‘mpm-prefork’ más común.
Usando esto, puede ir y definir el usuario / grupo que apache está usando cuando ejecuta cualquier script y, por ejemplo, crea directorios solo con este comando para cada entrada de host virtual en httpd.conf:
AssignUserId USER GROUP
Si realmente desea crear diferentes directorios a partir de la ejecución de UNA secuencia de comandos, necesita que el proceso de apache sea propiedad de root.root y luego la secuencia de comandos debe establecer los permisos y propietarios para cada directorio de la manera que desee.
Pero nunca es una buena idea ejecutar incluso los mejores scripts en un servidor web como root, ya que podría no pensar en ningún riesgo.
La separación de usuario / derecho por vhosts parece ser una forma de ahorro en mi opinión.
Otro punto, solo PHP, es suPHP -> http://www.suphp.org
EDITAR:
Ok, eché un vistazo a su sitio e incluso si no puedo hablar español, parece que tiene un solo sitio web, actuando para diferentes usuarios que vienen a través de esta página web. Entonces, ¿dónde está la necesidad de separación de usuarios en los permisos del sistema de archivos de Linux? Puede restringir todo por su aplicación sin necesidad de usuarios del sistema de archivos. Incluso si da, por ejemplo, acceso ftp adicional, restríjalo, por ejemplo, con proftpd, tiene su propio mecanismo chroot para diferentes usuarios.
Debería tener que preocuparse por los derechos del sistema de archivos solo si no puede controlar quién está ejecutando qué. Ese es un problema común en un host multidominio que podría resolver con el mpm_itk_module que mencioné.
¿Quizás deberías describir tu situación un poco más?
EDITAR 2:
Como se sugiere en el comentario, si SOLO usa apache para dar a los usuarios acceso a los archivos para cargar / manipular, entonces simplemente coloque los archivos fuera (!) Del árbol documentroot de apache y cree una base de datos simple para saber qué archivo es propiedad de cuál usuario:
user a | file parentdir/filename
Esta podría ser una tabla fácil y su código php le da al usuario una lista de la base de datos, qué archivo puede ver / manipular y su código hace el trabajo según lo previsto por la acción del usuario.
Siempre que no le dé al usuario acceso a los archivos por otros servicios (ftp, ssh, etc.) NO hay necesidad de trabajar con derechos de usuario de Linux en absoluto. Solo tenga cuidado de colocar los archivos fuera del documentroot del servidor para que solo su código php tenga acceso a los archivos por los derechos del usuario apache de su servidor.
EDITAR 3:
Jaja, ahora finalmente tengo tu problema después de leer una publicación similar tuya: (¿Cómo puede un usuario de Apache escribir archivos cuando tiene permisos para hacerlo?) En este caso (con usuarios REALMENTE anónimos en tu página web) NO tienes oportunidad de resolver esto en absoluto. Cada visitante es tratado como el mismo sin autenticación. Y como asumí en mi última EDICIÓN y comenté en una publicación similar: no es necesario manejar con permisos de archivos de Linux en absoluto.
SU SOLUCIÓN;): Necesita hacer la manipulación del archivo en una sesión con id de sesión mientras el usuario está visitando su página. Por lo tanto, su código debe manejar la relación entre el visitante (el ID de sesión) y el archivo que cargó con este ID de sesión. Usar una identificación de sesión que sea válida siempre que el visitante esté en línea es la mejor manera de hacerlo. Y de nuevo, no se necesitan permisos del sistema de archivos ….;)
La segunda forma es con usuarios autorizados como se sugirió anteriormente: cree una tabla db con usuarios / contraseñas para iniciar sesión en la página web (no en el servidor) y otra tabla que contenga las relaciones usuario / archivo. Luego, después de iniciar sesión en la página web, vuelva a trabajar con sesiones para permitir que el usuario acceda / manipule los archivos ya cargados.
Puedo que ejecutes apache con mod_php. Entonces significa que su instancia de PHP funciona bajo una instancia de apache y tiene apache USER y GROUP. Puede crear una carpeta y puede cambiar el propietario de esta carpeta, pero el propietario debe ser un usuario en su sistema (no apache o el mismo usuario virtual).
Pero puede almacenar en cada archivo de directorio, por ejemplo, “.permiciones” y poner en ese archivo el propietario virtual. A continuación, debe filtrar cada intento de escritura (eliminar, renombrar, etc.) en este directorio y comparar su usuario virtual y el usuario que se almacenó en el archivo .permitions.
Clase de muestra (no completa, pero es más que suficiente para comprender la idea):
class UserDirs
private $path='/home/vusers';
public function mkdir($user)
$d = $this->path.'/'.md5($user);
mkdir($d);
file_put_contents($d."/.owner",$user);
public function checkOwner($user, $dirname)
$f = $dirname."/.owner";
$virtual_owner = file_get_contents($f);
return $user === $virtual_owner;
$d = new UserDirs()
$d->mkdir("foo","bar");
echo $d->checkOwner("foo1","bar") === true ? "OK":"FAIL";
echo $d->checkOwner("foo","bar") === true ? "OK":"FAIL";
Puede encapsular todo lo que necesita en esta clase para trabajar con UserDirs y extender la clase según sus requisitos.
Sus usuarios no tienen cuentas del sistema. Probablemente tampoco sea factible crear esas cuentas. Por lo tanto, recomendaría administrar todo esto a través de la interfaz de usuario web.
Continúe creando sus directorios como está. Los permisos están bien. Sin embargo, su interfaz de usuario debe cambiar para mostrar solo el directorio o los archivos de ese usuario. Supongo que tiene una base de datos asociada a esta página. Asocie los nombres de usuario y el nombre del directorio generado aleatoriamente con el usuario. Si alguien intenta ir a la ruta directa y NO es el usuario asociado con ese directorio, devuélvalo a la pantalla de inicio de sesión.
Para ilustrar, creé una cuenta llamada test y presumiblemente se le dio un directorio único. Si me desconecto, no debería poder visitar ese directorio porque su código lo vería
- No he iniciado sesión y, por lo tanto, no tengo acceso a ese directorio.
Si tuviera que iniciar sesión como test2 y visite el directorio de test, tu código debería ver eso
- No soy el propietario del directorio que se está visitando y, por lo tanto, debería ser redirigido según corresponda.
Debe agregar una función que verifique el directorio que está visitando el usuario y compararlo con el directorio asociado con el usuario. Si los dos coinciden, permítales continuar. Si no coinciden, redirija al usuario.
Si tienes alguna desconfianza y capacidad de aclarar nuestro noticia puedes realizar un exégesis y con mucho placer lo observaremos.