Permisos incompatibles

Todo lo relacionado con seguridad y Security Server (RACF, LDAP, Etc)
Responder
pitu001
Usuario avanzado
Usuario avanzado
Mensajes: 37
Registrado: 28 Sep 2006, 02:34
País: España
Ciudad: Pamplona
Ocupación: Administrador de seguridad

Permisos incompatibles

Mensaje por pitu001 » 09 Nov 2011, 08:55

Hola a tod@s.
Tengo un perfil generico de un fichero protegido por unos permisos los grupos tienen lectura y los usuarios modificacion.
A su vez tengo un usuario que pertenece al grupo que necesita permiso de modificacion.
Hay alguna forma de conseguirlo. He intentado hacerlo al conectar el usuario al grupo con acces update, y con otras opciones que dan mas privilegios pero no lo he logrado. Creo que no se puede, ya que siempre se coge el privilegio mas restrictivo.
Muchas gracias.
Un saludo

Ejemplo, espero ser asi mas clara:
Fichero fichero1.datos1.*.**
permisos: grupo1 lectura
user1 modificacion
usuarios: user2 esta conectado al grupo1, por lo cual tiene permiso de lectura
pitu

Avatar de Usuario
Vicente
Colaborador avanzado
Colaborador avanzado
Mensajes: 543
Registrado: 21 Jul 2011, 04:52
País: España
Ciudad: Malaga
Ocupación: Técnico en Sistemas

Re: Permisos incompatibles

Mensaje por Vicente » 11 Nov 2011, 09:33

Hola pitu:

Como idea te propondría dividir cada grupo en dos:
Un grupo con permisos de lectura y el otro con permisos de modificación.
Así un usuario pertenecería solo a uno de los grupos, en función de lo que necesite.
Varios días probando, equivocandote y volviendo a probar
pueden ahorrarte quince minutos de lectura de un manual.

pitu001
Usuario avanzado
Usuario avanzado
Mensajes: 37
Registrado: 28 Sep 2006, 02:34
País: España
Ciudad: Pamplona
Ocupación: Administrador de seguridad

Re: Permisos incompatibles

Mensaje por pitu001 » 11 Nov 2011, 09:43

El asunto es que el usuario necesita permiso de modificacion, y a su vez tiene que pertenecer al grupo el cual tiene permiso de lectura...
Muchas gracias
pitu

Avatar de Usuario
Vicente
Colaborador avanzado
Colaborador avanzado
Mensajes: 543
Registrado: 21 Jul 2011, 04:52
País: España
Ciudad: Malaga
Ocupación: Técnico en Sistemas

Re: Permisos incompatibles

Mensaje por Vicente » 11 Nov 2011, 10:53

¿ Qué de especial tiene ese grupo que no puede ser dividido en dos, con los mismos privilegios que el original, excepto que uno de ellos solo tendría acceso en lectura a determinados ficheros ?
Varios días probando, equivocandote y volviendo a probar
pueden ahorrarte quince minutos de lectura de un manual.

Avatar de Usuario
gaston777
Usuario
Usuario
Mensajes: 20
Registrado: 05 Feb 2008, 21:03
Ubicación: Argentina, Buenos Aires

Re: Permisos incompatibles

Mensaje por gaston777 » 13 Nov 2011, 00:52

Hola,

en RACF, que un usuario esté conectado directamente al profile va a hacer un override del permiso que le de el grupo, es decir que si el grupo le da READ, pero pusiste al user directo con UPDATE, ese user va a tener permisos de modificación sobre dicho perfil.

Para que los cambios tomen efecto recordá siempre de refrescar la la clase (ya que NO es lógico realizar un IPL por cada modificación que uno realice)
Gaston Decuzzi
IBM Logical Security Specialist
Buenos Aires, Argentina

JuanG
Colaborador
Colaborador
Mensajes: 75
Registrado: 24 Nov 2003, 18:04
País: Argentina
Ciudad: Buenos Aires
Ocupación: Administrador de seguridad
Ubicación: Buenos Aires, Argentina

Re: Permisos incompatibles

Mensaje por JuanG » 15 Nov 2011, 14:50

Como dijo Gastón, en el algoritmo que usa RACF para responder un requerimiento de acceso, la presencia del usuario en la lista de acceso SIEMPRE toma preeminencia por sobre los eventuales grupos (a los que esté conectado) que también puedan figurar. A modo de ejemplo, si figura el usuario con NONE, aún cuando esté conectado a grupos con acceso ALTER, el usuario tendrá acceso NONE (es decir, no tendrá ningún acceso).

Con respecto a la necesidad de hacer un REFRESH para la clase DATASET, hay que tener cierta precaución (supongo que se usan solo perfiles genéricos, que hoy en día es lo mas habitual). Toda vez que un Address Space (AS) requiere el acceso a un dataset, se carga en su memoria virtual el perfil protector. De este modo, un acceso subsiguiente al mismo dataset, o a otro de nombre similar protegido por el mismo perfil, será otorgado más rápidamente, sin necesidad de recurrir a un costoso I/O sobre la base de RACF. Ahora bien, toda vez que se ejecuta el comando "SETR GENERIC(DATASET) REFRESH", automáticamente se invalidan a todas las copias de perfiles de DATASET que existen en la memoria de los distintos AS, forzando eventualmente una nueva carga (mediante un I/O). El comando termina inmediatamente, pero sus consecuencias en la performance pueden llegar a ser bastante negativas. Por lo tanto, si un usuario intentó acceder sin éxito a un archivo desde una sesión de TSO, y le fue solucionado su problema de acceso, es mas conveniente pedirle que salga y vuelva a entrar a TSO que ejecutar el citado comando de REFRESH. Si el intento de acceso fue a través de un job batch, directamente no es necesario ningún REFRESH. Al resubmitir el job, se tendrá en cuenta el perfil actualizado.

Saludos,
Juan

Responder