|
Situation: Occasionally I encounter a problem in which a device description is changed from a printer to a display (rarely, if ever, vice versa). New devices cannot be created automagically (QAUTOVRT = 0), but, if the device description already existed, the system pretty much ignored my wishes and changed the device from a printer to a display. There was no real security on the device descriptions (*Public = *Change) so I created an authorization list where just about everyone has *Use authority, except *Public and QTCP which are both *Exclude (maybe redundant but via both specific object authority and via the authorization list).
I am the object's owner so I used profile (MIKE) that has limited authority (and at a PC logged in by him), I ran Client Access -> Emulator -> Start or Configure Session, and created a "new" display session with the same id as a currently defined printer session. The device description is now a display, not a printer.
The security audit journal (QAUDJRN) shows (DO entries) that the printer device description was deleted by QTCP (previously showed that the outqueue for the printer had been deleted).The journal never shows the device being created, but it does show the object authority being changed for the device with an attribute of DSPVRT. There are no 'AF' entries in the QAUDJRN. I know that the minimal- user cannot delete the device description when secured by the authorization list. QTCP has *JOBCTL special authority, but that's it.
This (changing the device description's type) may be working "as designed," but it could be that I am just not defining the authorities correctly. I went through the Resource Security chapter [5] of the Security Reference manual for V5R4; following the flowcharts it looks like the attempt to re-define the device description should fail - but obviously does not.
For completeness, the object authority is:
Display Object Authority
Object . . . . . . . : PN Owner . . . . . . . : JERRY
Library . . . . . : QSYS Primary group . . . : *NONE
Object type . . . . : *DEVD ASP device . . . . . : *SYSBAS
Object secured by authorization list . . . . . . . . . . . . : PRINTERS
Object -----Object------ ------ Data-------
User Group Authority O M E A R R A U D E
*PUBLIC *EXCLUDE
JERRY *ALL X X X X X X X X X X
QTCP *EXCLUDE
The relevant parts of the authorizations list are:
Display Authorization List
Object . . . . . . . : PRINTERS Owner . . . . . . . : JERRY
Library . . . . . : QSYS Primary group . . . : *NONE
Object List -----Object------ ------Data-------
User Authority Mgt O M E A R R A U D E
*PUBLIC *EXCLUDE
JERRY *ALL X X X X X X X X X X X
MIKE *USE X X X
QTCP *EXCLUDE
I am no wiz at security, but I really thought I could nail this one down (prevent device types from changing). Not. After several days of experimentation and manual reading, I am throwing myself on your (tender?) mercies. Any clues, suggestions, rebukes, etc., would be appreciated.
Thanks.
Jerry C. Adams
IBM System i Programmer/Analyst
--
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.