Re: Workstation Object Getting Changed

John,

Thanks for the insights. What you describe is exactly what is happening.
Since we are running in the 36 environment, which uses ?WS? as part of
temporary file names, all of our devices are defined on the Client Access
session, such as PN (Printer) and D2 (Display).

During my testing, I found that for displays, if the user had *Use
authority, the user could not sign on to the display; i.e., they must have
*Change authority. However, for printer devices the user only needs *Use
authority.

I had investigated the issue the last time this happened (some months ago).
The only thing that I could find at the time was in the security audit
journal, which indicated that QTCP re-created the device. I thought/hoped
that defining QTCP's authority as *Exclude (both on the object and in the
authorization list) and changing all users (except for me) to *Use for
printers would prevent the re-creation. Alas, my testing over the last few
days disproved this - unless I have been incomplete in my definitions.

My only recourse to-date has been to define a list (SQL table) of the valid
devices and type. I have a scheduled job that runs each night that, if
there are any discrepancies, prints a report for me (I usually get in at
0600; most workstation users don't arrive until 0800). I retrieved the
source for each device; created a program for each; created a
command/program which could be used to re-create the device correctly.

Oh, I did find out that, when QTCP changed the printer to a display, it
occurred at an obscene time of around 0200 (we are basically a 10x5 shop:
0600-1630). Even though I could not find out who was creating the device.
Theoretically we are a "closed" shop (no access to the system from outside
the four walls), but you and I both know that where there's a will, there's
a way. Would an exit program help in this situation? On which exit point
would I apply it? I have never written/used an exit program so, if this is
viable, if anyone has or knows of one that might serve as a good
example/starting point, I would appreciate a link to it.

Thanks.

Jerry C. Adams
IBM System i Programmer/Analyst
--
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of John Earl
Sent: Friday, March 05, 2010 2:39 AM
To: Midrange Systems Technical Discussion
Subject: Re: Workstation Object Getting Changed

Jerry,

I am not 100% sure this applies to printer devices, but I know it
applies to telnet devices.

At session initiation, a telnet device description may be deleted and
recreated by the telnet system. The reason for this is so that the
telnet device description type will match the device description type
requested by the client. For example, If I connect to SYSTEMA and
request an emulation device type of VT100, the system creates a device
called QPADEV0001 that emulates a VT100 device type.

After I disconnect, you may connect using telnet and be assigned
device name QPADEV0001 also. However, your emulation client requests
a 3477 device type. Telnet then deletes the QPADEV0001 device type
(that I created) and makes a new QPADEV0001 with the proper device
type for you. Because you may not have the authority to delete the
device, this function is performed under the authority of user QTCP.

Now here is a really odd thing, even though you logged in and caused
this device to be created, if you didn't have the proper authority
(defined as *CHANGE or higher) to the previous device description (the
VT100 flavor that my emulation created), you will not be authorized to
use the device description that you (well, really, that user QTCP)
just created. A user must have *CHANGE authority to a device in order
to use it, but can delete and recreate a device they do not have
authority to (go figure).

Finally, If you are finding that a printer is being renamed to a
telnet device type, it is possible that one of your users has
specified the printer's name as their telnet device name and is
creating this problem for you. The easiest way I can think of smoking
that out is to list all the jobs of the printer's name from either
QAUDJRN or QHST and see which user's name is associated with the
printer's job name.

Hope this helps,

jte



On Mar 4, 2010, at 8:42 PM, Jim Franz wrote:

as odd as it may sound, i believe it's working as designed...
several years ago while working thru a virtual device problem an ibm
developer told me a device can be re-created for several reasons
(which
escape me now), and not go thru the normal delete device, create the
device,
or even a chg devd. I would take this to ibm and get a current
response to
the issue.
Jim Franz

----- Original Message -----
From: "Bdietz400" <bdietz400@xxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Thursday, March 04, 2010 9:08 PM
Subject: Re: Workstation Object Getting Changed

Maybe you could look at the telnet exit programs. Gould could
intercept the incoming device name/device type and deal with it.

Bryan

--
Bryan

Sent from my iPod Touch.



On Mar 4, 2010, at 4:32 PM, Jerry Adams <Jerry@xxxxxxxxxxxxxxx>
wrote:

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.

--
John Earl
President and CEO
Patrick Townsend Security Solutions
"The Encryption Company"

Olympia, WA | www.patownsend.com
Office: 360-357-8971 Ext 118

--
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.

--
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.