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 de Apache es el que crea directorios y archivos cuando ejecuta su script.
Si necesita la separación de usuarios para las secuencias de comandos, por ejemplo:tiene diferentes directorios para diferentes hosts (virtuales) en su servidor y no desea que la secuencia de comandos 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 más común 'mpm-prefork'.
Usando esto, puede ir y definir el usuario/grupo que Apache está usando cuando ejecuta cualquier script y, p. crea directorios simplemente con este comando para cada entrada de host virtual en httpd.conf:
<IfModule mpm_itk_module>
AssignUserId USER GROUP
</IfModule>
Si realmente desea crear directorios diferentes a partir de la ejecución de UN script, necesita que el proceso de apache sea propiedad de root.root y luego el script 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.
En mi opinión, la separación usuario/derecho por vhosts parece ser una forma mucho más económica.
Otro punto, solo PHP, es suPHP -> http://www.suphp.org
EDITAR:
Ok, eché un vistazo a su sitio y aunque no puedo hablar español, parece que tiene un solo sitio web, actuando para diferentes usuarios que vienen siempre 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 das, p. acceso ftp adicional:restringirlo, p. con proftpd tiene su propio chroot mech para diferentes usuarios.
Debería 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?
EDICIÓN 2:
Como se sugiere en el comentario, si SÓLO usa apache para dar a los usuarios acceso a los archivos para cargar/manipular, simplemente coloque los archivos fuera (!) del árbol documentroot de apache y cree una base de datos simple para saber qué archivo es propiedad de qué 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 a través de otros servicios (ftp, ssh, etc.), NO es necesario trabajar con los derechos de usuario de Linux. Solo tenga cuidado de colocar los archivos fuera de la raíz del documento del servidor para que solo su código php tenga acceso a los archivos con los derechos del usuario apache de su servidor.
EDICIÓN 3:
Jaja, ahora finalmente entendí 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 posibilidad 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 los permisos de archivos de Linux en absoluto.
TU SOLUCIÓN;) :Debes manipular el archivo en una sesión con identificadores de sesión mientras el usuario visita tu página. Por lo tanto, su código debe manejar la relación entre el visitante (la identificación de sesión) y el archivo que cargó con esta identificación de sesión. Usar una ID de sesión que sea válida mientras 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 autenticados 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. Entonces, después de iniciar sesión en la página web, vuelva a trabajar con las sesiones para permitir que el usuario acceda o manipule los archivos ya cargados.
Puedo que ejecute apache con mod_php. Entonces, significa que su instancia de PHP funciona bajo la instancia de apache y tiene USUARIO y GRUPO de apache. 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, ".permisos" y poner en ese archivo el propietario virtual. A continuación, debe filtrar cada intento de escritura (eliminación, cambio de nombre, etc.) en este directorio y comparar su usuario virtual y el usuario almacenado en el archivo .permitions.
Clase de muestra (no completa pero es más que suficiente para entender 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 tal 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 con 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, regréselo a la pantalla de inicio de sesión.
Para ilustrar, creé una cuenta llamada test y presumiblemente se le dio un directorio único. Si cierro la sesión, 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 visita el directorio de test , su código debería ver eso
- No soy el propietario del directorio que se está visitando y, por lo tanto, se me debe redirigir según corresponda.
Debe agregar una función que verifique el directorio que el usuario está visitando y lo compare con el directorio asociado con el usuario. Si los dos coinciden, permítales continuar. Si no coinciden, redirige al usuario.