Re: %seguridad a nivel registro

El jue, 02-03-2006 a las 09:10 -0600, Felipe de Jesus Molina Bravo
escribió:
> Creo que es muy específico al requerimiento, pero va:
>
> Estamos desarrollando un sistema; la bd, tendrá diferentes tipos de
> acceso. Uno de ellos es desde un sistema vía web. En este sistema se
> utiliza una sola cuenta para accesar a la bd, pero se tiene una tabla de
> usuarios para hacer una autenticación.
>
> Otro tipo de acceso es a través de un cliente de postgres, digamos el
> "psql". Por lo tanto ahi si requiero tener usuario de la bd. No me
> gustaría que estos usuarios rompieran las reglas de la bd.

Mmm. Creo que lo que necesitas es saber sobre GRANT y REVOKE.

> La verdad se me cerro el mundo y la solución es definir privilegios para
> esto usuarios.

No es facil. Considerando que tienes clientes de todo tipo. Esto me
suena a varios administradores (o sub administradores) mas clientes que
poblan (o pueblan?) las tablas, y desde distintas interfaces.

Lo que no es recomendable, es que los usuarios via web sean usuarios
postgres. No es mala idea, pero la aplicacion web tiene que ser muy
versatil y debe tener un muy buen control de los errores que se puedan
generar (dado que asumo que el usuario web es mas neofito con respecto a
las BD, comparado con el que accedera via psql, entonces los errores hay
que /traducirlos/). Ahora si el interfaz web es phpPgAdmin, la cosa
cambia. En ese caso debes crear usuarios reales en postgres.

Tambien no es malo que dos tipos de usuarios postgres se usen para el
acceso web. Uno con privilegios de solo SELECT, y otro con los
privilegios de UPDATE, INSERT, [DELETE]. Así te aseguras que no hagan
nada que te de dolores de cabeza en el futuro. Me refiero a crackeos por
falta de validacion de los campos de los formularios web.

La idea de varios administradores de frenton no la encuentro muy buena
(por algo en los paises no hay mas de un presidente simultaneamente, por
algo sera...).

Si, creo que definitivamente lo tuyo va por GRANT y REVOKE.

> Pido una disculpa, pero me ganaron las carreras.
>
> Aprovecho para preguntar... que lenguaje procedural es mas eficiente
> plperl, plpsql, plpyton, "c", etc? sin temor a equivocarme es "C", pero
> después quién le sigue? hasta ahora mi experiencia es con plpgsql y me
> va muy bien... pero me llama mucho la atención plperl.... que piensan?

Mmm. Esto puede ser un poco subjetivo. Yo empece a hacer proc con plPHP,
por que era lo unico que conocia, y la verdad que me funciona. Ahora por
un tema de eficiencia, me cambie a PL/pgsql por que es mas rapido (puede
ser subjetivo esto), pero segun lecturas arduas, mas lo que dice Alvaro
que es un entendido en esto, al mantener en memoria los planes de
ejecucion es mas eficiente ahi.

> Saludos y reitero la disculpa

A todos de vez en cuando nos piden resucitar a los dinosaurios...

Atte.
Juan Martínez
Depto. Inf.
UMC