Hola Martin, paso a explicarte lo que deberías hacer para tener esto disponible:
Crear un Rol (es lo que en otros motores el “Grupo de Usuarios”) para los usuarios de guarani (tanto los administrativos, como el usuario alumno, internet, etc…)
CREATE ROLE guarani;
Crear Role para ese usuario que se conectará desde otro lado.
CREATE ROLE usuarios_externos;
Al usuario “public” revocarle todos los permisos, es decir:
a) Sacar todos los permisos de SELECT/INSERT/DELETE/UPDATE de las tablas
b) Sacar todos los permisos de SELECT de las vistas
c) Sacar todos los permisos de EXECUTE de los procedures
Darle todos estos permisos del punto 3 al Role “guarani”
Solo dar permisos necesarios al rol “usuarios_externos”. Por ejemplo consulta de alguna vista creada para el usuario externo.
Asignar al Role “guarani” todos los usuarios de la base Guarani
Asignar al Role “usuarios_externos” ese/esos usuario/s que necesitan tener permiso de solo lectura
Modificar el proceso “sp_inicio_sesion” agregando la sentencia que indica que el usuario que se esta conectando a la base de datos de Guarani lo hará con el Role “guarani”
Esos otros usuarios cada vez que se conecten a la base, deberan indicar con que role se conectan, en este caso “usuarios_externos”.
Saludos.
Alejandro.
ALEJANDRO SI HAGO LO SIGUIENTE, funciona???:
CREATE ROLE usuario_ext;
grant usuario_ext to mde;
revoke all on vw_dni_alu from public;
grant select on vw_dni_alu to mde;
cree un role que se llame usuario_ext, le asigno el role al usuario mde, y hago un revoke para esa tabla a todos los usuarios public, y luego un select on para la vista.
creo que con esto no va a poder ver otras tablas.
igualmente este usuario necesita vincular esa vista por odbc, nada mas.
martin
Un poco tarde la respuesta pero espero te sirva.
Con respecto a esa vista, esta bien lo que haces. Recorda que al usar roles, cuando un usuario se conecte a la base, deberas explicitamente indicar que te estas conectando con ese role.
Igualmente, los permisos sobre las otras tablas/vistas/procedures ese usuario lo va a tener debido a que el usuario public tiene todos los permisos sobre estos objetos.
CREATE ROLE usuario_ext;
grant usuario_ext to ruso;
revoke all on vw_seguimientoEsteban from public;
grant select on vw_seguimientoEsteban to ruso;
SET ROLE ruso
pero al conectame por ODBC con ese usuario, en php no me devuelve nada, en cambio si lo pongo como public (grant select on vw_seguimientoEsteban to public;)me devuelve todo. Que me falta hacer?
Pablo, hice la siguiente prueba y se realizo la conexion sin problemas.
Informix
a. Quitar permisos al usuario “public”
b. Crear los roles necesarios
c. Asignar los roles a cada usuario
d. Asignar permisos a los roles (tablas, vistas, procedures…)
e. Agregar el campo “role_usuario” a la tabla de perfiles de usuarios para indicar el role de cada perfil funcional. Asignar el role de informix correspondiente a cada perfil funcional.
Se adjunta archivo informix.sql con ejemplo (Role PRUEBA).
Sistema - Guarani Gestion
a. Modificar la ventana w_conexion_informix, evento ue_pos_conectar_db
Sacar la seleccion a la propiedad “Extend Ancestor Script”
Copiar el codigo que se adjunta en el archivo guarani_roles.txt
Guarani web/wap: Agregar el código correspondiente al seteo del role según el usuario que se conecta a la base.
Se adjunta archivo guarani_roles.txt con codigo a agregar en el evento ue_pos_conectar_db.
De esta forma se puede setear dinamicamente el role del usuario que se conecta a Guarani. Como fue desarrollado solo permite un role por usuario.
Alejandro:
Te hago una consulta: tengo entendido que si un rol tiene permisos de ejecución sobre un store procedure, como en que casi por todos lados cuando se invoca un procedimiento se acompaña el nombre del procedimiento con el dueño del mismo, el sp se ejecuta con los permisos del dba. Es decir, el usuario tendría permiso sobre tablas que no tiene permiso en el rol al que pertenece.
Esto es efectivamente asi?
ANA
Durante la ejecucion de un procedure, el usuario que lo ejecuta recibe temporalmente los permisos del dueño del procedure. Tambien recibe el nivel RESOURCE o DBA, lo que que el dueño del procedure tuviera. Todos estos permisos se le dan temporalmente, es decir cuando termina de ejecutar el procedure los pierde.
Hay algunas excepciones, especificamente relacionadas con objetos (tablas) que use el procedure y que no sean propiedad del dueño del procedure. En estos casos el usuario que ejecuta solo recibe los permisos que el dueño del procure hubiera recibido con WITH GRANT OPTION