AS/400 - No permitir insert en una tabla

 
Vista:

No permitir insert en una tabla

Publicado por Antonio Galdamez (1 intervención) el 11/11/2010 17:23:50
Por Favor necesito ayuda:
Estamos trabajando en un ERP del cual no tenemos los fuentes y necesito bloquear el insert a una tabla. Ya modifique la autorización sobre la tabla para que no permite insert, pero de todos modos el programa que hace el insert lo sigue haciendo. Como repito no tengo los fuentes y este bloqueo lo queria hacer a nivel del sistema opertivo pero no me ha funcionado. La autorización actual esta así:

Usuario Grupo Objeto Lect. Adic Actual. Supr. Ejecutar
*PUBLIC *EXCLUDE
MGSA USER DEF X X X X
*GROUP GRPCOGNOS USER DEF X X X X
*GROUP GRPDESA USER DEF X X X X
*GROUP GRPSSAGU USER DEF X X X X
*GROUP GRPSSAPA USER DEF X X X X

El dueño del objeto es MGSA y el usuario con el que hice la prueba no tiene acceso al objeto, solo en su perfil tiene definido el grupo GRPSSAGU, pero igual puede hacer los insert.

Gracias.
Valora esta pregunta
Me gusta: Está pregunta es útil y esta claraNo me gusta: Está pregunta no esta clara o no es útil
0
Responder

RE:No permitir insert en una tabla

Publicado por Juan Carlos (14 intervenciones) el 03/12/2010 18:52:03
En principio, tal como pones las autorizaciones, el grupo GRPSSAGU tiene permisos de lectura, insercion, actualización y supresión sobre la tabla. Si el usuario con el que hiciste la prueba está en ese grupo, tiene las mismas autorizaciones.

De todas maneras, el tema tampoco es tan sencillo. Depende mucho de cómo esté accediendo tu ERP a las tablas del iSeries. Si es un ERP que utilice conexiones tipo ODBC, ADO.NET, JDBC, OLE DB ... es muy probable que en el propio programa estén montando su propia cadena de conexión y estén accediendo a la base de datos con un usuario que no tenga nada que ver con el que tiene el programa en ejecución. Incluso si se trata de aplicaciones nativas iSeries en RPG o COBOL, éstas pueden estar utilizando autorizaciones adoptadas, con lo cual el programa accede con los privilegios del usuario cuya autorización se adopta y no con las del usuario que la ejecuta.

Se me ocurre que una posible prueba sería asociarle un trigger a la tabla y comprobar en él qué usuario es el que está accediendo.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar