🚀 go-pugleaf

Hola, Alex:

Alex Estevez escribi� en es.comp.os.linux.programacion:

>> 
>> ...como nobody, que es quien est� ejecutando el servidor web, lo que ya
>> no es lo mismo que este "pete" afectando a root.
> 
> 
> Se suponia que programilla era un programa no shell con suid
> 

Hombre, si es un programilla que tiene el mismo contexto de seguridad que el
servidor web, lo puedes meter en la misma p�gina PHP.  "Romper" el proceso
tiene sentido cuando cambias el contexto de seguridad.

[...]

> 
>> Si en tu script utilizases la misma estrategia de saneamiento, s�; al no
>> utilizarla, es m�s dif�cil (exponencialmente m�s dif�cil) cometer el
>> error. De hecho, si se tratase de algo realmente cr�tico, la p�gina PHP y
>> el script cron deber�an escribirlos diferentes desarrolladores, por
>> supuesto, sin tener ning�n prejuicio sobre lo que el otro a hecho o ha
>> podido hacer para sanear los datos: a todos los efectos, se puede esperar
>> en la entrada de datos cualquier enga�o del maligno.
> 
> 
> cuantas estrategias hay para sanear un nombre de usuario? no creo que
> halla tantas. al fin y al cabo se limitara a permitir de A a Z, numeros y
> _

En un ejemplo tan sencillo, probablemente pocas.  Sin embargo, el contexto
ya es distinto: Ya no existen otras variables HTTP_ que se puedan
reescribir, por ejemplo y, como m�nimo, est�s revisando la cadena
solicitada dos veces en distintos programas.

> 
>> Si es tan poco elegante �por qu� permite cron ejecutar tareas cada
>> minuto?
> 
> No respondere sino es en presencia de mi abogado.
> 

Por supuesto, para gustos, los colores.

>> (Adem�s �tantos usuarios vas a crear que no se puede esperar diez
>> minutos, incluso una hora para obtener el resultado?).
> 
> No es tantos, sino en que tiempo. Se exige que la persona que cree uno o
> mas usuarios vea el resultado al momento (un minuto es bastante
> parecido). no en una hora o diez minutos... a mi me piden y yo hago :)
> 

Ya: eso lo entiendo.  Pero contra el vicio de pedir, est� la virtud de no
dar.  Hay que tratar de evitar que un usario sin conocimientos t�cnicos
trate de imponer al t�cnico restricciones t�cnicas, porque no est�
capacitado para ello.  Lo que tiene que hacer es explicarte *el problema*
(no la soluci�n deseada, ni mucho menos c�mo implementarla) y t� le dar�s
la soluci�n y su implementaci�n.  �A que no te han dicho algo del estilo de
"necesito un programa que me lea la mente y haga lo que pienso"?  Eso es
porque ya han tomado una determinaci�n de tipo t�cnico y tratan de
pas�rsela al t�cnico que la va a llevar a cabo.  Adem�s, que como suele
decirse, muchas veces los dioses para castigarnos nos conceden nuestros
deseos: si se le hubiese ocurrido y t� lo hubieses implantado, antes o
despu�s vendr�an a echarte la bronca porque en medio de una discusi�n
acalorada el fulano pens� "matar�a a este cabez�n", y tu programa �Z�s!

Desde el punto de vista del usuario *puede* ser mejor una confirmaci�n
instant�nea de la operaci�n, no lo dudo, pero no es *necesaria* (piensa en
las circunstancias en las que ser� necesaria la creaci�n de un nuevo
usuario y ver�s c�mo de cinco a diez minutos es un intervalo razonable). 
No siendo *necesaria* y entra�ando riesgos innecesarios, se pueden valorar
alternativas m�s adecuadas aunque se alejen del ideal pensado por el
usuario.

Por otra parte, si de lo �nico que se trata es de una p�gina web para crear
en esa misma m�quina un usuario...
1/ Te he dado ya otras dos posibilidades: suExec de Apache o utilizar un
programa compilado en lugar de un script, si lo vas a hacer t�.
2/ Buscar en Internet: seguro que encuentras m�s de un script/cgi para hacer
lo que pretendes (tendr�as seguramente que cambiar el c�digo para la
revisi�n de la base de datos, pero la parte de I/O ya la tendr�as
cubierta).
3/ Instalar webmin, retirar todos los m�dulos salvo el de alta de usuarios y
retocarlo (creo que todos los m�dulos est�n escritos en Perl).

> A modo de conclusion. he decidio realizar lo siguiente, para eliminar a
> su vez problemas con los ficheros de accesos simultaneos y demas.
> 
> El php. metera los datos en una BBDD Mysql
> 
> el cron lanzara cada minuto un programa que leera las nuevas entradas a
> esta BBDD y por cada uno creara el correspondiente usuario y demas
> gestiones que tenga que hacer.
> 
> El uso de Mysql no es solo para evitar problemas con los accesos
> simultaneos, es tambien para guardar en condiciones las cuentas creadas
> y otros datos.
> 

Esta es otra: tienes dos bases de datos (/etc/passwd y la DB en MySQL) con
informaci�n redundante.  Eso huele a chamusquina y, si es cierto lo que
digo (lo de que existir� informaci�n redundante) deber�a tratar de
evitarse.

> Ahora a su vez me surgen un par de dudas mas.
> 
> Que tal se maneja mysql con shellscripts? y que problemas me puede dar
> que halla que introducir un password al mysql?
> 

MySQL se maneja perfectamente desde script (mysqladmin es lo suficientemente
potente y por lo dem�s, puesto que se tratar� de pasar una serie de
sentencias SQL las puedes disponer en un fichero con el que alimentas al
gestor).  Respecto a las passwords, no se si te refieres a la del nuevo
usuario que vas a crear, o a la de acceso a la propia base de datos.  En el
primer caso, el problema no es distinto al que tendr�as con cualquier otro
programa: que un momento dado la contrase�a estar� en memoria: eso deber�a
ser un riesgo menor en una m�quina controlada.  Si es el segundo, deber�s
tener cuidado con los permisos que asignas al fichero, para que no quede al
alcance de ojos indiscretos.  Usar�s adem�s un login a la base de datos con
los m�nimos privilegios para realizar la tarea.

Por cierto, lo que no podr�s es guardar en MySQL la contrase�a utilizando la
funci�n crypt, porque es de una sola v�a.  Para crear el usuario
propondr�a, si es adecuado en tu entorno, utilizar siempre la misma
password en el momento de alta de la cuenta (con lo que no habr�a que
incluirla en la base de datos), o una distinta cada vez, creada
aleatoriamente y que se borra de la base de datos inmediatamente despu�s de
verificar que el alta ha sido llevada con �xito.
-- 
SALUD,
Jes�s
***
jesus_navarro@undominio.net
***