Estimados colegas.
Hace un par de d�as (quiz�s alguno m�s) que ando liado intentando integrar la gesti�n de usuarios de firebird, versi�n 2.5, desde una aplicaci�n lazarus (SQLDB). Despu�s de muchas pruebas decid� implementar tres disparadores en la tabla usuarios (la que manipulo desde lazarus). Estos disparadores son:

- De inserci�n, en el cual creo el nuevo usuario con su contrase�a, le asigno el rol seleccionado para este y genero el nuevo id.

- De actualizaci�n, en el cual si el nombre de usuario cambio, le quito los privilegios que tuviera y elimino el usuario, si cambio la contrase�a le asigno la nueva y si cambio el rol le quito el rol anterior y le asigno el nuevo.

- De eliminaci�n, quito los privilegios que tuviera y elimino el usuario.

Consideraciones:
- Para evitar conflictos, a�ado a los usuarios creados un prefijo.
- Todo lo referente a la gesti�n de usuarios lo ejecuto usando "execute statement".
- En el script de creaci�n de la BD (que se ejecuta como sysdba) creo tres usuarios, lo cual hace perfectamente.

El problema que tengo es que cuando accedo a la aplicaci�n con cualquiera de los 3 usuarios creados solo puedo manipular aquel con el que accedo. Seg�n la documentaci�n es lo normal para usuarios que no tiene el rol rdb$admin, que no es el caso, ya que en el script le a�ado ese rol.

Si quer�is os env�o el c�digo de los disparadores y de los procedimientos almacenados que orquestan lo arriba mencionado (ahora no es posible ;-D).

�Alguna idea?

El d�a 16 de septiembre de 2014, 7:11, Antonio Evora <aevorar en gmail.com> escribi�:

No soy partidario de crear usuarios en el motor, mejor usar 1 usuario y 1 rol predefinido en la base. Y llevar una tabla de usuarios en el cual le asignas los roles predefinidos.
Cuando creas 1 usuario debes propagar los privilegios a todas las vistas,tablas, procedimientos, etc

El 16/09/14 a las #4, Maxi escribi�:

Buenas Maxi.
Durante a�os lo he usado, como comentas, un solo usuario. Lo que no entiendo es esa asignaci�n que comentas de roles predefinidos, te refieres a roles de la BD o a roles de la aplicaci�n, entendiendo esto ultimo por los distintos perfiles que yo pueda definir para mi aplicaci�n sin tener nada que ver con la BD. Entiendo que este �nico usuario debe de tener acceso y privilegios en todos los objetos que se manipulen desde la aplicaci�n. Si el escenario propuesto es as�, veo que supone un problema de seguridad, cualquier usuario malintencionado que descubra ese usuario y contrase�a maestro podr�a conectarse a la BD y hacer todo lo que le apetezca, sin posibilidad de registrar quien hizo la conexi�n (todos se conectan de la misma manera).

O lo suyo es hacerlo como comentas y mantener un bit�coras de todo lo que se va haciendo en la BD.

Necesito iluminaci�n, estoy de crisis existencial ;)

El d�a 16 de septiembre de 2014, 11:27, Antonio �vora <aevorar en gmail.com> escribi�:

En firebird, la seguridad la perdes cuando podes acceder al archivo, o a la instalacion del motor cambiando un archivo security2.fdb por uno tuyo y ya. Pero eso es paranoico.

Puedes usar Alias y no saber como se llama el verdadero usuario.

Lo que te digo con los roles es en la BD. Con este rol puedes agrupar usuarios con permisos determinado para ciertos objetos de la BD, que creo es lo que pretendes.

Si usas un solo usuario, en tus tablas debes poner triggers que disparen un los desde que terminal fue hecho. Pero si ya logr� acceder a la BD con un usuario de privilegio, puede eliminar dentro lo que quiera.

La complejidad depende de lo que quieras proteger

Gracias Maxi.
Volvemos a revision anterior y sigo trabajando como lo hacia antes.

Gracias de nuevo por iluminarme.

El 16/09/14 a las #4, Maxi escribi�: