Permisos incompatibles

[pitu001]

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

[Vicente]

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.

[pitu001]

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

[Vicente]

¿ 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 ?

[gaston777]

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)

[JuanG]

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,