T12SPLZ - Teknoda tips

Notas técnicas de AS/400 - Tips en detalle Nro. 12
(Lo nuevo, lo escondido, o simplemente lo de siempre pero bien explicado)
"Tips en breve/Tips en detalle" se envía con frecuencia variable y absolutamente sin cargo como un servicio a nuestros
clientes AS/400. Contiene principalmente notas técnicas y no contiene mensajes publicitarios.
Conteste este mail con asunto “REMOVER” si no desea recibir más esta publicación. . Si desea suscribir otra dirección
de e-mail para que comience a recibir los “Tips”, envíe un mensaje desde esa dirección a letter400@teknoda.com.ar,
aclarando nombre, empresa y cargo del suscriptor.
Lista de Tips publicados hasta la fecha:
1.
Modificación de los parámetros por default que rigen en los comandos del OS/400
2.
Restricción de comandos pesados a modalidad batch
3.
Cómo generar un entorno de prueba para año 2000
4.
Cómo salvar y restaurar spool
5.
Cómo agregar pantallas de confirmación/validación para comandos delicados
6.
Defragmentación del espacio en disco no utilizado : STRDSKRGZ, ENDDSKRGZ
7.
Manipulación de bases de datos desde programas CL, a través de Query/400
8.
Generación de spool AS/400 en formato PDF (Adobe Acrobat Reader) para almacenar en CD´s
9.
Cómo proteger columnas de un archivo físico o lógico
10.
Cómo cambiar la pantalla de signon
11.
Cómo automatizar transferencias de archivos con TCP/IP desde AS/400
Temas de próximos tips:

Auditoría sobre objetos en AS/400

Usos prácticos del NETSERVER

Recuperación de archivos dañados
CONTROL DE ACCESOS SOBRE ARCHIVOS DE SPOOL
Tema:
Seguridad, Spool.
Utilidad:
Protección de información confidencial del spool.
Nivel:
Avanzado
Versión:
Todas
Introducción
Toda la información que se deposita en forma de archivos de spool también necesita estar protegida de los
accesos no debidos por parte de usuarios no autorizados. A pesar de utilizar comúnmente la denominación
“archivos de spool”, es importante aclarar que los mismos no son objetos de tipo *FILE, sino items o
elementos que se encuentran almacenados en objetos de tipo *OUTQ o colas de salida. Cada vez que
desde un job se genera una salida impresa, ésta se almacena dentro de una cola de salida.
A las colas de salida (objetos tipo *OUTQ) como a cualquier otro objeto del sistema, se les aplican las
autorizaciones específicas ya conocidas como *ALL, *CHANGE, *USE, *EXCLUDE y User Defined. Sin
embargo, debido a la complejidad estructural de este tipo de objeto y a la exposición que recibe en su
manipuleo, existen parámetros de seguridad adicionales que deben considerarse.
Asimismo, hay que tener en cuenta que el acceso al spool está MUY relacionado con la concesión de
autorizaciones especiales, esto es, las colas de salida suelen estar muy expuestas ante los usuarios operadores,
administradores, etc.
El presente tip, permitirá conocer qué relación existe entre las autorizaciones específicas, los parámetros de
seguridad de las colas de salida y las autorizaciones especiales que los usuarios poseen.
Estructura básica de la seguridad de spool
Contrariamente a lo que muchos suponen, no es necesario poseer autorizaciones especiales de operador
(*JOBCTL) para poder manipular spool. Cualquier usuario “raso”, en caso de tener acceso a las
funciones/comandos de manejo de colas de salida puede gestionarlas dentro de las limitaciones que le impone
la seguridad de las colas de salida.
De acuerdo a los valores por defecto del sistema, un usuario sin autorizaciones especiales (*USER y *PGMR)
puede visualizar, imprimir, cambiar o eliminar un listado mientras éste le pertenezca, es decir, si el
listado fue generado por un job bajo su propio perfil. Si hubiera otros listados en la misma cola de salida,
este usuario podrá detectar que existen, pero sin posibilidad de operar con ellos. En otras palabras, cualquier
usuario puede ser “operador” de sus propios listados.
Si además este usuario es propietario del objeto cola de salida, puede también dentro de los parámetros de
seguridad establecidos por default, operar sobre todos los listados de la cola.
En la mayoría de los casos, no es necesario hacer una administración especial de la seguridad de spool para
este tipo de usuarios “rasos”. Puede requerirse alguna acción en el caso de que se quiera darle acceso a los
listados de otros, por ejemplo, o vedarle la visualización de sus propios listados. Desde ya, las restricciones
más fuertes (*EXCLUDE) que se apliquen sobre cualquier cola de salida afectan a esta categoría de usuario,
que no tiene atribuciones especiales que le permitan sortear la limitación.
Para conocer con más detalle el comportamiento del sistema hacia estos usuarios y cómo modificarlo, es
necesario analizar (además de la seguridad del objeto *OUTQ) los parámetros Autorización a comprobar
(palabra clave AUTCHK) y Visualizar cualquier archivo (palabra clave DSPDTA). Estos forman parte de
los atributos de la cola de salida, y se visualizan al crearla o modificarla (ver pantalla).:
Crear cola de salida (CRTOUTQ)
Teclee elecciones, pulse Intro.
Parámetros Adicionales
Visualizar cualquier archivo . .
*NO
*NO, *YES, *OWNER
Separadores de trabajos
. . . .
0
0-9, *MSG
Controlado por operador
. . . .
*YES
*YES, *NO
*NONE
Nombre, *NONE
Cola de datos
. . . . . . . . .
Biblioteca . . . . . . . . . .
Nombre, *LIBL, *CURLIB
Autorización a comprobar . . . .
*OWNER
*OWNER, *DTAAUT
Autorización . . . . . . . . . .
*USE
Nombre, *USE, *ALL...
Cuando el valor AUTCHK está en *OWNER (default), OS/400 chequea si el usuario que accede a la cola de
salida es el propietario de la misma. Si es así, cualquier operación está permitida siFinal
los valores para el
parámetro DSPDTA son *YES o *NO. En cambio, si el valor de DSPDTA es *OWNER, el propietario de la
F3=Salir
F4=Solicitud
F5=Renovar
F12=Cancelar
cola de salida sólo podrá realizar la gestión operativa aunque sea el dueño de la OUTQ. Si el usuario que
F13=Cómo
utilizar
esta
pantalla
F24=Más
teclas
quiere
trabajar con
los archivos
de spool
no es el propietario
de la cola
de salida, sólo se podrá visualizar el
contenido cuando DSPDTA valga *YES. En los demás valores de este parámetro, ninguna operación estará
permitida.
Si el valor de AUTCHK es *DTAAUT, se considerarán exclusivamente los permisos del usuario sobre el
objeto cola de salida. Para tener permiso a la mayor parte de las operaciones sobre la misma, se necesitará
autorización específica *CHANGE. Es importante observar que la autorización pública por default que posee
una cola de salida es *USE y no *CHANGE como ocurre para la mayor parte de los objetos (si fuera
*CHANGE, los permisos a cualquier usuario serían excesivos para este tipo de objeto).
Ejemplo:
Utilizando los parámetros anteriormente explicados, es posible plantear combinaciones muy interesantes que
nos permiten generar colas de salida sobre las cuales los usuarios posean diferentes tipos de accesos. Por
ejemplo, se necesita una cola de salida para un grupo de programadores. Cualquiera de los archivos de spool
deberá ser accedido por los diferentes integrantes del grupo, independientemente quién fue el que lo generó.
Para cumplir con este requerimiento, la cola de salida debe tener como propietario a un usuario externo al
grupo, y los parámetros de seguridad, a saber, AUTCHK y DSPDTA deberán valer *OWNER y *YES
respectivamente. Al grupo en cuestión se le otorgará la autorización *CHANGE sobre la cola de salida. De
esta manera, todos podrán visualizar el contenido de los archivos de spool de los demás.
Acceso con autorización especial *JOBCTL: La zona peligrosa
Los operadores y muchas veces también los programadores son usuarios que gozan de la autorización especial
*JOBCTL. Esta autorización le permite al que la posee, entre otras cosas, gestionar listados propios y
ajenos de cualquier cola de salida del sistema, siempre y cuando sus parámetros de seguridad estén en
sus valores por defecto, independientemente de las autorizaciones específicas del objeto (observar el
recorrido en rojo en la Figura 1).
Un usuario *JOBCTL, cuando accede al spool, está en situación de efectuar “casi”cualquier operación sobre
los archivos, aunque se hubiera especificado *EXCLUDE para la cola de salida en forma pública o privada.
El tipo de gestión que se puede llevar a cabo sobre el spool es dependiente del parámetro Visualizar
cualquier archivo (palabra clave DSPDTA). Si este último está en *YES o *NO (observar que *NO es el
default) entonces cualquier operación puede efectuarse. De aquí se deduce que si un usuario es *JOBCTL y
los parámetros de seguridad de la *OUTQ están en sus defaults, el acceso es total. En caso contrario, si el
valor es *OWNER, las operaciones permitidas son aquellas relacionadas con operación (retener, liberar,
cambiar atributos y suprimir). La combinación de los parámetros OPRCTL = *YES y DSPDTA = *OWNER
está orientada a permitir a los operadores la gestión de las entradas sin que tengan permiso a visualizar
su contenido.
En caso de querer modificar este default, existe la posibilidad de alterar el parámetro OPRCTL (Controlable
por operador) de la cola que se desea proteger, colocándolo en *NO en lugar del valor por defecto, *YES.
Cualquier usuario con autoridad *JOBCTL que acceda a la misma, lo hará en las condiciones de
cualquier otro usuario que no posea autorizaciones especiales, es decir se inhibirá el valor *JOBCTL
para esa cola en particular y el sistema efectuará los chequeos de seguridad que se aplican a un usuario
sin autorizaciones especiales.
Por todo lo hasta aquí expuesto, poseer la autoridad *JOBCTL proporciona accesos respecto al spool que
pueden llegar a ser más amplios de lo necesario. Por lo tanto el otorgamiento de *JOBCTL debería estar
estrictamente controlado. Antes de la V3R7 del OS/400, cada vez que se creaba un perfil de usuario de clase
*SECADM, *SYSOPR o *PGMR se otorgaban las autorizaciones especiales *JOBCTL y *SAVSYS (el
administrador además gozaba de la autorización *SECADM). Desde la V3R7 en adelante, OS/400 comenzó a
restringir la asignación automática de autorizaciones especiales. El administrador de seguridad conserva
solamente la autorización *SECADM, el operador del sistema posee las mismas y el programador
directamente no posee autorizaciones especiales. Para efectuar tareas netamente de programación, un
perfil de usuario no necesita autorizaciones especiales.
Ejemplos:

El oficial de seguridad necesita una cola de salida donde volcar los archivos de spool que se generan con
información confidencial de seguridad. Para cumplir con este objetivo, crear el objeto *OUTQ con el
oficial de seguridad como propietario. Los parámetros de seguridad deberían establecerse en los
siguientes valores: OPRCTL en *NO (acceso no permitido a los usuarios con *JOBCTL), AUTCHK en
*DTAAUT (se necesita autorización específica sobre el objeto *OUTQ) y DSPDTA en *OWNER
(ninguna operación permitida). La autorización pública del objeto en *EXCLUDE cierra el acceso a
cualquier otro usuario.

Para la impresión de archivos confidenciales se necesita una cola de salida donde los usuarios puedan
volcar esa información y los operadores puedan realizar la gestión operativa de los mismos sin visualizar
su contenido. Los parámetros de seguridad deben establecerse de la siguiente forma: OPRCTL en *YES
(habilita a los usuarios con *JOBCTL), AUTCHK en *OWNER (chequea si el que accede es el
propietario de la *OUTQ) y DSPDTA en *OWNER ( los usuarios sólo pueden trabajar con su propio
spool y el operador podrá retener, liberar, cambiar y eliminar). La autorización pública debería valer
*USE.
Acceso con autorización especial *SPLTCL: Acceso absoluto
Los perfiles poseedores de este permiso, tienen acceso completo a los archivos de spool de cualquier cola
de salida para efectuar todo tipo de operación. Si un perfil goza de esta autorización, es imposible evitar su
acceso a una determinada cola de salida. La autorización especial *SPLCTL sólo es concedida por OS/400 a
los usuarios de clase oficial de seguridad (*SECOFR), aunque también puede otorgarse individualmente.
Resumen de parámetros de seguridad de las colas de salida
El siguiente esquema en la Figura 1 representa el chequeo de autorizaciones que efectúa el sistema para
acceder a archivos de spool considerando las autorizaciones especiales del usuario, los parámetros
anteriormente mencionados de las colas de salida y las autorizaciones específicas sobre el objeto:
Chequeo de autorizaciones para acceder a los
archivos de spool
Parámetros de seguridad Parámetro
de una cola de salida en DSPDTA
los comandos:
OPRCTL
CRTOUTQ, CHGOUTQ y
AUTCHK
WRKOUTQD.
Es * SPLCTL ?
Si
Valores
(* NO/* YES/* OWNER) Visualizar cualquier archivo
(* YES/* NO)
Si
No
OPRCTL
TODO
Tareas permitidas sobre
archivos de spool de
otros usuarios:
VIS incluye DSP, CPY y
SND
OPE incluye HLD, CHG,
DLT y RLS
Controlado por operador
( * OWNER/* DTAAUT) Autorización a comprobar
Es * JOBCTL ?
No
Descripción
* YES
* NO
AUTCHK
* OWNER
* DTAAUT
Usuario es ow ner?
Si
* DTAAUT
DSPDTA:
DSPDTA:
DSPDTA:
* YES: VIS; con
* CHANGE, TODO.
DSPDTA:
* YES: VIS
* YES o * NO:
TODO
* NO: nada, con
* CHANGE TODO.
* NO o
* OWNER:
Nada
* YES o * NO:
TODO
* OWNER:
OPE
TODO = VIS + OPE
No
* OWNER:
OPE
* OWNER: nada;
con * CHANGE,
OPE.
FIGURA 1
Para tener en cuenta...

Recuerde que cuando un usuario genera un archivo de spool, es el propietario del listado. Por lo tanto,
siempre podrá verlos y manipularlos sin tener en cuenta como se definió la seguridad para la cola de
salida que utilice.

El texto “Controlable por operador” del parámetro de palabra clave OPRCTL puede conducir a
confusiones. Recordar que no se refiere a la clase de usuario, sino al hecho de poseer la autorización
especial *JOBCTL. La acción de este parámetro involucraría también a un usuario de clase *PGMR, si
él también posee dicho permiso especial.

Los parámetros de las colas de salida pueden indicarse tanto en el momento de su creación (comando
CRTOUTQ), o con un cambio posterior (comando CHGOUTQ). Para visualizar los valores en uso se
utiliza el mandato WRKOUTQD.

La autorización especial *ALLOBJ sobre colas de salida no se comporta de la misma manera que sobre
otros tipos de objetos.

La autorización especial *SPLCTL puede interpretarse como el *ALLOBJ de las colas de salida.

Para determinar donde se almacena un archivo de spool generado por un job, se efectúan una serie de
consultas en la siguiente secuencia: “printer file”, atributos del trabajo, perfil de usuario, descripción de
dispositivo de pantalla y por último el valor de sistema QPRTDEV.
Copyright 2000 Teknoda S.A. - AS/400 y OS/400 son marcas registradas de IBM.
Dudas o consultas a gmperez@teknoda.com.ar o nsalmun@teknoda.com.ar