A mechanism for providing security to a dual decor command host system

Description of equivalent WO 9609705 A1

0001A Mechanism for Providing Security to a Dual Decor Command Host System

0002BACKGROUND OF THE INVENTION Field of Use

0003The present invention relates to the emulation of one computer system by another computer system, and more particularly to software emulation.

0004Prior Art

0005With the rapid evolution of higher speed computer systems and new microprocessor chip designs, users now have even a greater need to have their application programs written for a specific computer system run on different computer systems. Moreover, it becomes more important than ever to provide this capability without having to convert or port such application programs. Therefore, a number of vendors have developed both hardware and software approaches to achieve this result without having to convert or port such application programs.

0006One prior art system achieves the above by providing the capability of running a plurality of different operating systems. Each operating system is defined as having an interior decor and are utilized by an apparatus which isolates the operating systems and ensures that only the instructions of the currently active operating system are executed. This system is disclosed in U.S. Patent No. 4, 530,052 to James . King entitled, "Apparatus and Method for a Data Processing Unit Sharing a Plurality of Operating Systems" which issued on July 16, 1985 and is assigned to the assignee named herein. This system has the limitation of not being able to run more than one operating system at a time.

0007Another prior art system provides a plurality of central processing units each of which tightly couples together and utilizes a different type of operating system. The central processing units in combination with their operating systems operate in a peer relationship in which all systems have access to all system resources. To ensure the integrity of the most secure of the operating systems (i.e., deemed the proprietary operating system), certain mechanisms are included in the system for enforcing certain restrictions on the other less secure operating system (i.e., deemed the non-proprietary operating systems). These restrictions are that a non-proprietary operating system can only access memory allocated by the proprietary operating system and can use only those channels and input/output instructions specifically assigned by the proprietary operating system. Stated differently, mechanisms are provided to prevent the intentional or unintentional use of resources not assigned to the particular central processing unit and operating system combination.

0008The above system is disclosed in U.S. Patent Nos. 5,027,271 and 5,230,065 invented by John L. Curley, et al. entitled, "Apparatus and Method for Alterable Resource Partitioning Enforcement in a Data Processing System Having Central Processing Units using Different Operating Systems" and "Apparatus and Method for a Data Processing System Having a Peer Relationship Among a Plurality of Central Processing Units" which issued on June 25, 1991 and July 20, 1993, respectively, and are assigned to the same assignee as named herein. It will be noted that while this system enables the running of more than one operating system, it requires the use of separate independent central processing units and mechanisms for enforcing the use of only assigned system resources.

0009When running different operating systems within a system, it becomes desirable to provide a user with the capability of utilizing both systems in an efficient manner. In the prior art system of U.S. Patent No. 5,230,065, a user is allowed access to both operating systems through a user registration process performed on the proprietary operating system whose results are then transferred to the non-proprietary operating system. When a user has been registered on the proprietary operating system as having access to both systems, the user can issue a special switch command which switches the user's terminal over to the non-proprietary operating system. The switch command allows permanent access (i.e., access until logout from the current session) or temporary access (i.e., access to execute a single command) to the non- proprietary operating system. During this access, the user is able to issue commands while running on the non-proprietary operating system which may for example allow the transfer of data to the other operating system. For a further description of this system and operations, reference may be made to the publication entitled "GCOS6 HVS6 PLUS XC Processor Systems Basics" published by Bull HN Information Systems Inc., dated December, 1991, order number LH39-02.

0010While the above prior art arrangement allows a user access to both operating systems, such access takes place at the user level while both operating systems maintain their independent mode of operation. It will be noted that this type of access capability can only be invoked at a high level and still requires user interaction with both operating systems as independent entities. Hence, this capability was in effect built on top of both operating systems, relying heavily on a user's ability to issue the proper sequence of commands to both systems for the execution of the appropriate procedures by each operating system. This arrangement is less efficient since it can be very cumbersome and time consuming to use.

0011Further, the above prior art arrangement does not provide for stringent security enforcement within both operating systems. That is, the proprietary operating system validates security as to unauthorized access for the entire system through the proprietary operating system's log-in mechanism. As to security for preventing compromises in data, the system includes mechanisms which enable the proprietary operating system to enforce resource restrictions on the non-proprietary system. Thus, this type of approach would not be effective in systems such as that of the present invention in the case where the application programs being run on the proprietary operating system are the application programs which are required to be emulated by the host system.

0012Furthermore, in the type of prior art proprietary operating system contemplated, information disclosing a substantial part of the organization of the operating system and its associated data structures historically have been made accessible to users. Therefore, it is likely that a knowledgeable user could intentionally or unintentionally alter the operating system data structures defining the user's identity and data access rights to gain access to other user system data files. Since this type of activity would go undetected in the prior art system and therefore unpreventable, this would result in significant compromises in system security.

0013Accordingly, it is a primary object of the present invention to provide access to host facilities for more efficient execution of application programs being emulated on a host system.

0014It is another object of the present invention to provide a method and system which enables application programs running in an emulation environment on a host system to be efficiently executed in a highly secure manner.

0015It is still another object of the present invention to provide a method and system for executing application programs running in an emulation environment on a host system which requires no changes to the host system operating system facilities thereby facilitating software enhancement and support. SUMMARY OF THE INVENTION

0016The above and other objects of the present invention are achieved in a preferred embodiment of the host data processing system of the present invention which includes a plurality of input/output devices and operates under the control of a non-proprietary operating system. In the preferred embodiment, the operating system is an enhanced version of the UNIX operating system known as the AIX™operating system developed by IBM Corporation. The host system includes an emulator which runs as an application process for executing user emulated system (ES) application programs which in the preferred embodiment were originally written for use on the DPS6 and DPS6000 family of computers and the GCOS6™ and HVS operating systems developed by Bull HN Information Systems Inc.

0017The emulator includes a number of emulated system executive service components (e.g., HVS executive service components) operating in ES and host system shared memory environment and an interpreter, an emulator monitor call unit (EMCU) and a number of server facilities operating in the host system memory environment. The ES executive service components are extended and modified to accommodate a number of dual decor commands and functions which make host system facilities directly available to ES application programs by concurrent execution of program operations within both emulator and host system environments.

0018The EMCU includes mechanisms for performing an initial level security validation operation which allows subsequent trusted verification of user identity when dual decor commands or functions are invoked. The server facilities include mechanisms for performing a two step security validation process for ensuring security relative to preventing both unauthorized user access and compromises in user data through improper use of dual decor commands or functions. The first step validates security at the user level and the second step validates security at the file level.

0019More specifically, first, the system validates that the user invoking the operation is in fact a trusted dual decor user. This is carried out by using a unique encrypted description entry of each dual decor user which was previously stored in a user table located in the host memory environment which is inaccessible to ES users. The storing of the entry is done as part of the login procedure in which the ES system, upon verifying that the user is a dual decor user, issues a special monitor call to the EMCU. After validating that the special monitor call came from the proper source, the EMCU verifies that the user is an authorized host system user through the host encrypted password facilities. Once the user identity has been authenticated, the ES system creates the appropriate entry in the user table, which uniquely defines the personality of the user.

0020In accordance with the present invention, this encrypted description entry has three basic parts or components. These are: the emulated system user id itself which, during the log-in procedure, was established as matching the host user identification; the address of a first emulated system data structure defining the location of the user control block (UCB) and the address of a second emulated system data structure defining the location of the group control block (GCB). The addresses of each set of these data structures are uniquely assigned to a user by the appropriate ES system component during login and only a single copy for any given ES user exists in memory. By maintaining this set of uniquely assigned addresses of these data structures and associating them with the user id, the system of the present invention is now able to determine during the first step of the verification that the user is a trusted dual decor user at the point when a dual decor command or function is invoked by the user.

0021The user personality is validated by the EMCU confirming that original description or personality of the user has not been changed. That is, the user has not changed the user id so that it no longer is associated with the same set of UCB and GCB originally assigned addresses indicating that the user's personality has been changed.

0022If the user description is established as being valid, then the required type of server facilities are created or assigned and necessary connections are made between the server facilities and the ES component which initiated the dual decor command or operation.

0023If the system determines that the user invoking the dual decor command or function is not a legitimate dual decor user, the system takes no further action (i.e., does not establish the necessary connections) to execute the dual decor command or function. Thus, there is no way for the user to have the command or function executed thus ensuring security. The user is notified of the violation by the particular ES component which initiated the operation. The second step is performed by the server facilities at the file or directory level at file access time (open) using the built-in file protection mechanisms of the host system to compare the user permissions within the group to which the user belongs against the permissions associated with the data files to be accessed to verify that they are correct. If correct, the requested operation is allowed to proceed. If the user is determined as not having the required level of permission, the server facilities do not perform the requested operation and the user is notified of the access security violation.

0024In the preferred embodiment, a dynamic server handler (DSH) included as part of the server facilities performs the first step of the security validation operation for essentially all of the different types of dual decor commands and functions. The access check step is performed at a lower level by a server assigned or created by the DSH unit to perform the particular dual decor operation. Access control checking is done at a lower level where it can be executed by the specific type of server designed to handle that operation and for more effective validation of each type of dual decor file access requests (e.g., open, read, write). For example, this arrangement ensures security in those situations where it is not possible to determine the type of access being requested by a particular user before an initial phase of the operation is allowed to take place.

0025In accordance with the teachings of the present invention, a number of different types of dual decor commands or functions are provided as part of the dual decor facilities. Dual decor commands and functions are designated in two ways. They are designated in the form of new commands or as extensions to existing commands such as by the inclusion of uniquely designed arguments designating host system entities (e.g., host path or procedure names).

0026The dual decor commands and f nctions allow an emulated system user to augment execution of their emulated system application programs with host application programs and mechanisms. The present invention provides these capabilities through the integration of dual decor functionality within the emulation facilities which makes certain operations easier to perform using single or combinations of dual decor commands.

0027For example, one dual decor command known as an XShell command, can be used to replace an existing application such as an office automation application with an equivalent host application. Other dual decor commands can be used to take advantage of the host file and data transfer mechanisms. For example, a user can use a command known as a CopyX command to move files in the ES system to the host system from where they can be transferred to another system via the host system's file transfer facility (FTP) which can be invoked by an XShell command.

0028Additionally, dual decor commands then can be used to perform operations on files located in both systems during the same session. Also, dual decor commands can be used to perform operations on a file previously maintained by the ES system which is now being maintained by the host system (e.g., a dump file). A dual decor command known as a link file command, can be used to link together directory files located in both systems so that a given ES program such as an editor, can be used to edit files on both systems during the same session. Another form of the same command can be used to enable programs within the two systems work cooperatively to carry out a given operation. For example, a link pipe version of the command can be used to provide host named pipes facilities for enabling the output data from an ES program to be used as the input to a host program or visa versa while both programs are being executed by their respective systems. These are some of the basic features and advantages provided by the preferred embodiment of the present invention. These features and functions allows users to make the transition from an emulated system environment to a host system at their own pace. For further information regarding these commands, reference may be made to the referenced related copending patent applications.

0029The above objects and advantages of the present invention will be better understood from the following description when taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

0031Figure 1 is a block diagram of a host system which incorporates the dual decor functionality according to the teachings of the present invention.

0032Figures 2a through 3b are flow diagrams used in describing the operation of the present invention. DESCRIPTION OF THE PREFERRED EMBODIMENT

0033Figure 1 is a block diagram of a host system 54 which incorporates the dual decor components of the present invention. As shown, the system 54 includes a hardware platform 56 which contains the hardware elements such as a central processing unit 58a, a main memory 58b and a number of input/output peripheral/communications devices including a local area network for connecting system 54 to other processing systems via standard communication network facilities.

0034The central processing unit (CPU) represented by block 58a is a reduced instruction set (RISC) based processing unit which takes the form of the RS6000 microprocessor manufactured by IBM corporation. The hardware platform 56 may also take the form of the DPX/20 system marketed by Bull HN Information Systems Inc.

0035As seen from Figure 1, hardware platform including processing unit 58a operates under the control of an enhanced version of the UNIX™ operating system such as the AIX™ operating system. Portions of physical memory represented by MEM block 58b are illustrated in terms of the layered construction. As shown, memory is divided into two basic levels, a user level and an operating system level. The user level is divided into emulated system (ES) and host shared memory space and host or an operating system kernel native memory space. The shared memory space contains the ES executive level 16 which includes a plurality of executive program tasks 30 spawned by ES executive services components of block 28 for executing ES application programs 22 and system administrator programs 24.

0036In the emulated system, each task 30 utilizes a plurality of data control structures, such as a task control block (TCB) structure 32, an indirect request block (IRB) structure 36, an input/output request block (IORB) structure 38 and a resource control table (RCT) structure 40. The task control block (TCB) structure 32 contains information pertaining to the state of execution of the associated task as well as pointers to interrupt save areas for storing hardware parameters related to the task. The indirect request block (IRB) structure 36 contains information defining the operation requested by an associated task and includes pointers identifying the task and its associated task control block (TCB) and a pointer to the associated IORB structure.

0037The input/output request block (IORB) structure 38 is used as the standard means of requesting a physical I/O service. It contains information such as a logical resource number (LRN) that identifies the I/O device being addressed as well as the location and size of the buffer to be used for the transfer and the specific function (operation) requested. The resource control table (RCT) structure 40 contains information describing the resources, such as its characteristics or information regarding the tasks or requests being executed by a corresponding resource as well as pointers to its associated task control block (TCB) structure.

0038Additionally, two other structures depicted in Figure 1 utilized by the present invention are a group control block (GCB) structure and a user control block structure of block 29. The GCB structure contains information required to define and control the operations of a specific task group which defines a named set of one or more tasks with a common set of resources within which a user and system function must operate. Each group has a two character name (e.g., SL, $S) by which the group is uniquely known to the system. The GCB structure includes information identifying the lead task whose execution spawns all other tasks required for executing group programs. As indicated, the GCB structure includes a number of user control blocks (UCB), each of which contains information defining the user's personality such as user node identification, user group id within a node, user task id within group, user person id and pointer information to directories to which the user has access.

0039As shown, the emulated system utilizes a further data structure corresponding to system control block (SCB) structure 27. This data structure is created at system startup and contains information defining system resources and pointers to the different task groups established by the system represented by a corresponding number of group control blocks in the system . For further information regarding such structures and their relationships to each other, reference may be made to U.S. Patent No. 5,111,384 and the publication entitled "HVS PLUS Systems Concepts" published by Bull HN Information Systems Inc., Order No. HE03-01.

0040As indicated in Figure 1, the shared memory space further includes a memory queued interface (MQI) represented by block 84 which provides a form of interprocess communication mechanism and a software active queue (SAQ) of block 88. SAQ block 88 represents a data structure used to provide the path by which the results of the operations performed by the kernel level components are passed back or returned by the host processes to the requesting emulated system user level tasks 30 being executed. Thus, it can be viewed as functioning as an output stage of MQI 84. This data structure is similar to data structures which are used by the emulated system operating system..

0041MQI block 84 is a semaphore data structure which takes the form of a single linked list controlled by semaphores through a set of routines which are executed by the various host processes operating within different levels or layers that want to communicate with each other. Its routines are used to manage queues within the pseudo device drivers 74 and the software active queue 88.

0042Executive Services Components 28

0043As seen in Figure 1, the executive services components 28 of executive layer 16 includes a plurality of components or facilities which are equivalent to those facilities normally included in emulated system. The facilities utilized by the present invention include a listener module 280, a file management facility 282, a monitor call unit 284 and a ES command handler unit 286 which are arranged as shown. The listener module 280 is responsible for monitoring the operations of terminals configured for login and for initiating user tasks in response to user commands. As indicated in Figure 1, listener module 280 runs as a task 30 with its own set of unique data structures.

0044As described herein, the listener module 280 is able to consult a profiles file containing user specific registration information such as user id, login id and password requirements tabulated by the system administrator for all registered users. The listener module 280 checks the user profile when monitoring the privileges and/or restrictions given to each user. The file management facility 282 includes the conventional shared data structure and set of routines normally provided to perform functions that access such data structure to control the synchronization of concurrent processes or tasks in addition to performing various system services or functions. That is, the facility responds to system service monitor calls identifying the types of services requested (e.g. creating or deleting files, reading or writing records or blocks in files) which result in the specified system services being executed by the emulated system on behalf of executing user application programs.

0045The monitor call unit 284 receives monitor calls from the interpreter component 72 which are in turn to be executed interpretively using the ES executive service components of block 28. The command handler unit 286 contains the routines that respond to user commands entered via a terminal or program. In response to such commands, the unit 286 routines invoke the appropriate tasks for executing such commands. As discussed herein in greater detail, each of these components have been augmented or extended to incorporate different dual decor aspects or features according to the teachings of the present invention.

0046Emulator level laver 68

0047As indicated in Figure 1, the next layer within the user level is the emulator executive level 68. This level includes certain components present in the emulated system which have been transformed into new mechanisms which appear to the remaining unchanged components to operate as the original unchanged components of the emulated system. At the same time, these new mechanisms appear to the components of the kernel level 64 as native components with which the host system is accustomed to operate. As shown, the components include the interpreter 72, an emulator monitor call unit (EMCU) 73, a plurality of servers 90, through 940, and a plurality of pseudo device drivers (PSDD) 74 arranged as shown.

0048Additionally, level 68 includes a data structure in the form of user table 96 which contains entries which uniquely define the personalities of the different dual decor users. This table is maintained to be able to determine that a given user has successfully gone through the login procedure. In accordance with the present invention, each such encrypted user description entry has three basic parts or components. These are: the emulated system user id itself which during the log-in procedure was previously established as matching the host user identification; the address of a first emulated system data structure defining the location of the user control block (UCB) and the address of a second emulated system data structure defining the location of the user group control block (GCB). The Appendix shows the format of these entries in greater detail.

0049The interpreter 72 successively fetches the instructions of an emulated system application program, categorizes each instruction and executes it interpretively through sequences of RISC instructions which allows CPU 58a, MEM 58b and other elements of host system 54 to emulate the operations of corresponding elements of the emulated system. The interpreter 72 includes a monitor call (MCL) table containing information for each possible monitor call which it utilizes to determine whether to trap or send an ES monitor call to the ES executive services components 28 for execution of the instruction or to make an emulator call to EMCU 73 for execution of the instruction through the services of an appropriate C language routine (server). The EMCU 73 is responsible for acquiring from the host system 54, the necessary memory and other resources, for initializing the emulated system data structures and invoking interpreter 72 and the various server processes. Both the interpreter 72 and EMCU 73 run as host processes but not as root.

0050As viewed by the host system, the ES service components 28 and tasks 30 being executed on behalf of the application programs, the interpreter 72 and EMCU 73 are executed in the system 54 of Figure 1 as a single process 80 wherein such process corresponds to one or more user processes as defined by the conventions of the host operating system being run on host system 54. Thus, it is possible to have multiple instances of the emulated system concurrently emulated on host system 54.

0051The password server 90, the dynamic server handler (DSH) 92 and the network terminal driver (NTD) server 94 are created by EMCU 73 during initialization. Each of the servers 90, 92 and 94 communicate with emulated system processes through MQI 84 as indicated. The lower level group of servers 920, 922 and 940 are dynamically created by their respective higher level servers 92 and 94 for carrying dual decor operations according to the present invention. All of the servers operate as root and therefore have super user privileges with access to any file within the host system 54. The NTD server 94 is designed to contain the functionality required to handle different types of terminals such as the network terminal driver described in U.S. Patent No. 4,951,245 which issued on August 21, 1990.

0052As described in detail herein, both the servers 92 and 94 include mechanisms specifically designed for validating security at the user level in conjunction with the execution of dual decor commands and functions. As shown in Figure 1 , the lower level group of servers 920, 922 and 940, each include access control mechanisms used to validate security at the file level. In the case of server 940, host access control mechanisms are used.

0053As indicated in Figure 1, the EMCU 73, dynamic server handler 92 and NTD server 94, each have access to a data structure in the form of a user table (USRTBL) 96 which has been located in host space so as to be inaccessible to ES user application programs. As described herein in greater detail, the table 96 contains encrypted user descriptor information which is used for validating a user's identity according to the teachings of the present invention. The encryption ensures security in the event of a memory dump. As indicated in Figure 1, the emulator executive level 68 further includes a plurality of pseudo devices drivers (PSDD) 74 for each input/output device or type of input/output device which is required to be emulated by host system 54. For example, the pseudo device drivers 74 will include PSDDs for terminals, disk drivers, tape drivers, displays and for certain communication devices.

0054For a more detailed discussion of other aspects of the SAQ 88, MQI block 84, PSDD 74 and other emulator components, reference may be made to the related patent application.

0055Operating System/Kernel Level

0056The operating system/kernel level 64 includes the standard mechanisms and components normally included within the host operating system. As shown, level 64 includes a kernel process manager component 70, a host user password file 700, a host crypt password service facility 702, Inode permission files storage 704 and a number of host kernel I/O services (KIOS) processes 66 for each pseudo device driver (PSDD) 74 which is to be emulated by the host system and for each of the servers 920 through 940 assigned to execute dual decor commands and functions. Since the components of the kernel level 64 are well known, they are only briefly described herein. The host user password file 700 is used for storing information identifying registered host users. This file is updated and maintained by the host operating system kernel process manager 70. A part of the information stored in the password file 700 is the user encrypted password generated using the one way crypt password service facility 702 invoked by the kernel process manager 70.

0057The Inode permission files storage contains entries listing the attributes and disk addresses of each file in the system. Each Inode entry contains information about the type, size, times, ownership and disk blocks in each inode. The directory structure in the host system uses entries, each of which contains just a file name and its Inode number. The attributes of an entry include references to access control lists (ACLs) defining the file's base and any extended permissions. The base permissions correspond to the traditional file access modes (i.e., read, write and execute/search) assigned to a file owner, file group and other users. The extended permissions designate how the base permissions have been modified in terms of permitting, denying or specifying access modes for specific individuals, groups, or user and group combinations designated by user and group ids. For the purpose of the present invention, this arrangement can be considered conventional in design.

0058Additionally, in the preferred embodiment of host system 54, level 64 is assumed to contain the standard utility programs, shell, editors, compilers, etc. and libraries (e.g., I/O libraries, open, close) which are accessed in the host user mode. For further information regarding the use of such arrangements, reference may be made to publications of the IBM Corporation describing the AIX operating system.

DESCRIPTION OF OPERATION

0060With reference to the flow charts of Figures 2a through 3b, the set of dual decor commands and functions incorporated into the system 54 according to the teachings of the present invention will now be described. As diagrammatically illustrated in Figure 1, dual decor commands and functions encompass new commands and extensions to existing commands of the emulated system command set. The commands include a file copy command (CPX), a shell command (XSH), and an enhanced version of an emulated system link command (LK).

0061The CPX command provides the ability to copy or transfer a file in either direction between the emulated system and the host system. The XSH command provides the ability to activate and deactivate host procedures through host system facilities by the execution of synchronous and asynchronous shell commands. The LK command provides the ability for emulated system application programs with access to different types of host files. These include text files and host named pipes accessed to create interprocess communications between concurrently executed emulated and host systems application programs for enabling cooperative processing.

0062The formats of these commands are set forth in the Appendix and are also described in detail in the referenced related patent applications. It will be noted from the Appendix that enhanced or augmented emulated system commands, such as the different type of LK commands, each utilizes a predetermined variable such as an upper case x which is followed by a colon (i.e., "X:) to denote its dual decor aspects.

0063As denoted by the shaded boxes in Figure 1, the different components of block 28 have been augmented to accommodate the set of dual decor commands and functions. The listener module 280 has been augmented to incorporate a validation routine which is invoked when a user logs on the emulated system. This causes the operations of Figure 2a to take place during ES user login. Loeon Procedure

0064Referring to Figure 2a, it is seen that listener module 280 first prompts the user to enter his or her name (i.e., user id) as in the case of a standard system login procedure (block 200). Next, the listener module 280 upon receipt of the user id, looks up the emulated system user profile to verify if the user is a dual decor user (block 202). More specifically, the emulated system like other systems maintains a user profile record for each authorized user of the system for security and accounting purposes. The profile record normally contains information such as the user-id, access restrictions, type of terminal, etc. As part of such access restrictions, the profile record includes a particular field coded for indicating if the user is a dual decor user. When the field is set to a predetermined value (i.e., a binary ONE), this indicates that the user is authorized to execute dual decor commands and functions.

0065If listener module 280 determines that the user is a dual decor user (block 204), it then takes the appropriate action to validate that the user is an authorized dual decor user which requires that the user is registered on the host system as an authorized host system user by the system administrator. This requires the ES user logging in to have the same login name (userjd) as the host system login name. This requirement is carried out by validating the userjd as described herein. As indicated in Figure 2a, the userjd is first tried to be validated with a NULL password (blocks 206 and 208). That is, listener module 280 issues a special monitor call (MCL 3721- 0) accompanied with a NULL password. To ensure tight security, this type of monitor call can only be issued by listener module 280. The term validate as used herein refers to calling for the encryption of the password string and comparing the output of the crypt password service unit 702 corresponding to the encrypted password string with the host user entry obtained from the host user password file 700.

0066The special monitor call is received by EMCU 73 which has been augmented by additional routines, as denoted by the shaded block, to perform the requested validation operation. This is done through password server 90 which makes a series of system calls to the host operating system kernel. But, before doing that, as part of the monitor call, EMCU 73 performs a series of checks to authenticate that the call was in fact issued by listener module 280 and not by an impersonator. This includes checking that the listener module 280 is running in ring 0 (i.e., has the highest privilege) in addition to other kinds of checks such as verifying its group id. That is, since listener module 280 runs as a task within the emulated system, it has its own unique set of GCB and UCB data structures, which can be used in performing such checks. In this way, the system ensures that there is a trusted path to the host system by which the identity of the dual decor user can be validated.

0067The listener module 280 special monitor call invokes the password server 90 which in turn obtains the encrypted ES user password from the host user password file 700. Also, the special monitor call causes EMCU 73 to invoke the host crypt password service unit 702 to encrypt the NULL password and to compare the encrypted NULL password with the ES user password. If there is no comparison, then a no result is returned by EMCU 73 to the listener module 280. If there is a comparison, then a yes result is returned to listener module 280 by EMCU 73.

0068In the case of a comparison, EMCU 73 creates a preliminary user table entry within user table 96 which includes the listener control block address. It also increments by one, a dual decor token utilized for proper tracking of licenses. Next, as indicated in Figure 2b, listener module 280 examines the returned result (block 210). When the response comes back that the NULL password was valid (block 210 or 220), the user need not be prompted for a password. If the response came back that the NULL password was not valid, listener module 280 then prompts the user for his or her password (block 214). Then, listener module 280 reissues the special monitor call along with the user entered password to determine if this password is valid (block 216).

0069As indicated in Figure 2b, the operations of block 208 are repeated (block 218) and listener module 280 again examines the result (block 220). That is, the password provided by the user is encrypted and the crypt output is compared with the host password file entry for the ES user obtained by the password server 90. If the response is that the user password was not valid, the listener module 280 again prompts the user for another password and reissues the special monitor call. This sequence is repeated three times (block 222). If the response is still the same after the third try, then listener module 280 discontinues the procedure and returns to the beginning of the login sequence.

0070If response came back that the password was valid, listener module 280 creates the emulated system task group and its associated GCB and UCB structures equivalent to the GCB and UCB structures of block 29 in Figure 1 (block 224). Next, listener module 280 verifies that the create group request did not fail (i.e., the group was successfully spawned by the emulated system components) (block 226).

0071If for any reason the group could not be successfully spawned (e.g., insufficient memory available for that user), this event is detected and results in the listener module 280 issuing another type of the special monitor call (MCL3721-2) to EMCU 73 (block 228). This results in the EMCU 73 clearing the preliminary user table entry within the user table 96 in addition to restoring the dual decor token to its previous value (block 230). As indicated in Figure 2c, these operations are followed by listener module 280 reporting the action taken to the user and issuing an emulated system login banner followed by a return to the beginning of the login procedure (block 234).

0072When the listener module 280 verifies that the group was successfully created, then it issues another type of special monitor call (MCL 3721-1) to EMCU 73 (block 232). This causes EMCU 73 to finalize the preliminary table entry in user table 96 wherein the address of the GCB is changed from that of the listener module GCB to that of the user GCB (block 236). Next, listener module 280 completes the user log¬ in procedure (block 240).

0073The result of the login procedure is that the user table 96 now contains a unique description of the dual decor user (its personality) which the listener module 280 created for that user during the login procedure. More specifically, the description contains the userjd which is now associated with the addresses of that user's GCB and UCB data structures. Since it is not possible to change these addresses due to the way in which they are assigned by the emulated system, any change in userjd information would be readily detectable as a violation of the host system's trusted path established by its login procedure. Furthermore, the user description information is also encrypted further ensuring security in that it will not be discernible in the case of a memory dump.

0074Command Execution Flow

0075The present invention utilizes the unique user descriptions contained in user table 96 in carrying out security checks during the execution of commands issued by a user to prevent non-dual decor (unauthorized host) users from invoking such commands or functions. Figures 3a and 3b illustrate the user overall command execution flow. Referring to Figure 3a, the circles labeled 300 through 306 represent the different kinds of commands which are available to a user. Of particular relevance to the present invention are the commands which are included as a part of the dual decor functionality.

0076As discussed above, the different components of block 28 have been augmented. More specifically, the file management component 282 has been modified to incoφorate the necessary hooks and mechanisms which support each of the different types of LK commands. The command handler unit 284 has been augmented to include mechanisms which support the CPX and XSH commands in addition to certain aspects of the LK command.

0077During operation, when a command is issued by a user via a terminal device, the command invokes a command processor (not shown) included within block 28. The command processor is a system software component that reads each command line entered by the user through a terminal or from a command file and then passes it to the appropriate command handler within block 286 for execution.

0078In the case of certain types of dual decor commands and functions, the processing of a dual decor command causes the generation of a special monitor call by the particular command handler. This is done for the puφose of obtaining necessary resource identification information such as a logical resource number (LRN) value required for communicating with system tasks and devices. Thereafter, the command handler directly or indirectly causes the generation of a request for I O monitor call (RQIO).

0079It will be noted that in the case of the link command, this command can be performed without invoking a dual decor function. That is, in the emulated system, any command can be used to establish a link within a directory or file without invoking dual decor runctionability. It is only when the link mechanism is actually used to access host system files that the dual decor functionality may be invoked. Thus, as indicated in Figure 3a, other monitor calls are examined by the file management component 284 to determine if access is being made to the host file system using link files or pipes (block 308). If it is, the file management component 284 issues a request for I/O monitor call. If no such access is being made, then the command is executed by the emulated system in the normal manner (block 310).

0080As seen from Figure 3a, the RQIO monitor call to the EMCU 73 by each of the dual decor invoked components 28 results in a user level security check being performed by one of the high level servers 92 or 94 which is selected as a function of the type of dual decor command. In greater detail, in the case of certain types of dual decor functions (e.g., CPX command), the accompanying IORB data structure of RQIO monitor call includes information specifying the type of I/O operation requested and whether or not a host server process has been created to execute the operation. Assuming that no server process has been created as determined by the LRN value contained in the RCT entry, EMCU 73 transfers the request IORB by enqueuing it onto the MQI 84 queue section of either the dynamic server handler 92 in the case of CPX and XSH commands or onto the queue section of the NTD server 94 in the case of XSH commands.

0081Assuming that the request was forwarded to the dynamic server handler 92, in accordance with the present invention, DSH 92 performs the user level security check to validate that the command was issued by a trustworthy dual decor user ensuring that system security is not being compromised (block 312). More specifically, DSH 92 determines if the user is legitimately logged in with a valid host password. This is done by validating the user's personality by first obtaining the UCB and GCB addresses from shared memory for the user invoking the dual decor function through information stored in the IRB structure obtained from the TCB whose address is contained in the IORB. These addresses are compared against the encrypted addresses in the description entry for that user stored in the user table 96. This operation is carried out through the use of a common get user access control routine.

0082The user access routine causes encrypting of the current user descriptor information (i.e., user-id, GCB and UCB addresses) and a comparison of these three components of information with the encrypted information obtained from the user table 96. When there is no identical comparison in the case of all three fields, this indicates that the current user is not trustworthy and will compromise security. That is, the user access routine verifies that the GCB and UCB addresses associated with user id used during login have not changed.

0083If the user security can not be validated, DSH 92 takes no action to make a connection but simply reports the user level security violation to the user (block 316). Depending upon the type of dual decor command or operation, other actions may be taken by the executive component which initiated the request on behalf of the user. For example, in the case of the file management component 284, the task which attempted to do the operation may be killed. Since DSH 92 took no action to make the requested connection, the user has no way to carry out the dual decor command or function.

0084If the user security is validated (block 314), then DSH 92 opens the connection between the appropriate server and the executive service component which invoked the dual decor command or function on behalf of the user. More specifically, as indicated in Figure 3b, it first determines which server is required to handle the request by referencing the device type information contained within the associated RCT. If no server of the type specified has been created or can be assigned, DSH 92 creates server process through the host fork system call mechanism and passes all of the information about the user to the server through MQI 84 (block 318). More specifically, the IORB is enqueued by DSH 92 onto the MQI queue assigned to the server which is to execute dual decor commands or functions. Next, DSH 92 establishes the connection between the assigned server and the user so that all future requests go directly to that server. This is done by modifying the RCT so that all subsequent requests will be directly sent to that server.

0085As indicated in Figure 3 b, the assigned server performs an access check at the file or directory level on the request (block 320). This is done by the server making a call to a get access function which by additional calls determines if the particular user id can perform the specific type of operation on a given file. The same common routine is used by each of the different types of servers to perform this type of access check.

0086The access check involves referencing the Inode permissions files 704 through system calls to kernel process manager 70. As indicated above, the Inode files 704 include file owner identifier information (i.e., individual owner and group owner and the sets of users who have access rights to the file) file type information (e.g. regular, directory, FIFO pipes) and file access permission information. This obtains all of the permissions at the particular user Inode and verifies whether or not the user has the required permissions. The result is that a three bit code is generated by the server for indicating read, write and execute permissions. When there is an access violation, this information is used in reporting the type of violation to the ES executive component which issued the request (blocks 320 and 324). As indicated in Figure 3b, when the server determines that access is valid, then the server performs the specified dual decor command or function and reports the results to the ES user via MQI 84 (block 326). The access check of block 320 takes place at "file access time" which in the host system is the first step a process must take to access the data in a host file. In the case of the host system open system call, there is information specifying the type of open (e.g. reading or writing). In the emulated system, a dual decor user can issue commands or functions which precede a logical connect of the host system operation which is equivalent to the open. For example, this is the case where the ES user reserves a file by issuing a get file command causing the file management system 282 to issue an RQIO in the form of a physical connect.

0087In this case, the DSH server performs the security operations of blocks 312 through 318 as described above. The assigned lower level server performs the access control check of block 320 also in the manner described above in response to the physical connect operation. But, since there is no way to determine the type of operation to be performed on the file, only the directory files are checked and it is determined that the user has sufficient permission to open the file. At the time when the logical connect (open) is issued indicating the type of operation at file access time, this request goes directly to the assigned server which performs an extensive permissions check which includes also verifying the user access permission through the basic and extended permissions. Any violation is signaled in the above manner.

0088The arrangement enables the access check of block 320 to be made specified or tailored as a function to the type of operation being performed to enforce the appropriate level security. The access check can therefore be performed on opens, reads or writes as required. Hence, tight security is maintained notwithstanding the type of dual decor command or function being extended. Further, performing access checking at this end enhances the security of the emulated systems wherein it was not always possible to determine the type of access being requested before an initial phase of the operation was allowed to take place.

0089From the above, it can be seen how the present invention processes dual decor commands and functions in a manner which maintains the level of tight security which is characteristic of the host system 54. It accomplishes it by integrating dual decor functions within the different executive services components of the emulated system and by adding special monitor calls and additional server facilities to the emulation executive level layer so as to have the host system operating system remain in tact. Page A- 1 APPENDIX A

DUAL DECOR COMPONENTS

0091******************************************************************************

0092Emulated System Specialized Monitor Call Handlers

0093****************************************************************************** extern char "base, *sys_ιO, *usr_r0, *curr_asv, iy___n[]; extern struct USRTBL *qhdu; extern ulong *ssdt_ptr; /* pointer to subsdt */ extern char *crypt(); extern unsigned int _π_address; extern unsigned short config_dual_decor_users; extern unsigned short logged_on_dual_users; extern char *get_base_session_name();

0094^* **************

0095* _ncl_cpx_lm * 370f - Return unreserved dual decor lπι to CPX/XSH/etc.

0096******** *******^ void mc._cpx_lrn(rr) struct RISC.REGS *rτ;

0097{ struct GCB *gcb; struct LRT *lrt; struct RCT *rct; int bu_id, oldmas . nodstat; char xsh_pipe_name[MAXPATHLEN + 20), *session_id; if (!(allowed("ddcor")))

0098{ rr->rl = PRTV_VIOLATION; return;

0099) if (!(bu_id = bound_unil(rr)))

0100{ rr->rl = PRIV_VIOLAΗON; return;

0101) if ((bu id == NXSH ID) && (rτ->r2))

0102( lrt = (struct LRT *) lr__address;

0103RISC_ADDR(rcU (struct RCT *), (lτt->rt_rct + rτ->r2 * 2)); ret s (struct RCT *) ((char *) ret - OFF_RCT); if (rct->qaddr.fιldes[l])

0104{ close(rct->qaddr.fildes[ 1 ]); rct->qaddr.nides[l] = 0; } /* pipe is open */ rr->rl = SUCCESS_CODE; } /* NXSH close pipe */ else { if (rr->r2 = get_ddcor rct(bu_id))

0105{ switch (bu_id)

0106{ case CPXJD: Page A-2

0107rr->rl = SUCCESS_CODE; break; case NXSHJD: /* Get the Session's Instance Name */ session_id = get_base_session_name(); /* Set up the IORB Pipe Name */ sprintf(xsh_pipe_n---.e, "%sNxsh_%d". session_id, rr->r2); oldmask = -unask(O); do nodstat = mknod(xsh_pipe_name,

0108(S.IFIFO I S_IRWXU I S_IRWXG I S_IRWXO). 0); while ((nodstat < 0) && (ermo == EIΝTR)); umask(oldmask); /* restore old mask */ if (nodstat < 0)

0109{ syslog(LOG_ERR, "E851: ΝXSH Unable to create pipe %s: %m", xsh_pipe_name); rr->rl = UΝAVL_CODE; break;

0110} rr->rl = SUCCESS_CODE; break; default: rr->rl = PRTV_VIOLAT10N; break; } /* switch */

0111} else

0112{ rr->rl = UNAVL_CODE; syslog(LOG_E R. "E744: DDECOR (%s) No available LRN", iya ); } } } /* mcLcpx_lm */

0113/***************

0114* mc linkJrn * 3720 - Return LINK lπi

0115•a*************/ void mcl_Iink__m(rr) struct RISC_REGS *rr;

0116{ struct HDM *hdm_base; struct SCB *scb; struct GCB *gcb; struct LRT *lrt; struct RCT *rct; int i; long ssz; if (!(allowed("ddcor")))

0117{ rτ->rl = PRJV VIOLATION; return; Page A-3

0118} hdm_base = (struct HDM *) sys_rf);

0119RISC_ADDR(scb, (struct SCB *), bdm_base->h_scb);

0120RISC_ADDR(ssz, (long), scb->s_ssz); if (MCLng(rr)) return; if (rr->p >= ssz)

0121{ rr->rl = ARG_NG; return;

0122} /*

0123* look for a free entry on the ddecor free queue */ if (rr->r2 = get_ddcor_rct(LNK_ID))

0124{ rr->rl = SUCCESS_CODE; } /* if available Ink */ else

0125{ rr->rl = UNAVL_CODE; syslog(LOG_ERR, "E745: LINK No available LRN");

0126} } /* mcljinkjm */

0127/*************

0128* mc login * 3721 • Listener login (ES to Host)

0129*_••*_•********

0130/*

0131* r2=0: Listener login :: bl -> ltrb; b2 -> user profile; b3 -> password

0132* r2=l: Login level 2 :: bl -> gcb; b7 -> Itrb

0133* r2=2: logout :: bl -> ltrb

0134* r2=3: Reconnect :: same as 0 - except do not count dual decor users

0135*

0136* on return: rl=0 success; rl !=0 failure */ void π_c._login(rr) struct RISC_REGS *rr;

0137{ static char person[14], passwd[14], salt[3]; static char spaces[] = " "; static struct USRTBL *us tr, *qptr; static struct GCB *gcb; static struct TCB *tcb; static int i; static char *ptr; unsigned long breg_addr; if ((is_it_listener(rr)) && (allowed("ddcor")))

0138{ if ((logged_on_dual_users >= confϊg_dual_decor_users) && (π->r2 = 0)) { rr->rl = MAX_USERS; Page A- 4

0139return;

0140) get_ac__qheadO; switch (rr->r2)

0141{ case PRIM.LOGIN: case RECONNECT: case VALIDATE:

0142TRANSL_RISC_BREG(ptr, (char *), rr->b2); memcpy(person, &ptr[6), 12); /* ???? */ person[12] = "\0'; if (ptr = (str-hr(person, ' ')))

0143{

0144*ptr = Λ0';

0145} else

0146{ if (ptr = (strchi person, '."))) * \r -= ^•\0^•■,

0147) if (strlen(person) >= L_cuserid)

0148{ rr->rl = 0x1204; /* ????? */ syslog(LOG_ERR, "E732: user name too long : ^<7. s", person); break;

0149} for (i = 0; i &lt; strlen(ρerson); i++)

0150{ if (isupper(person[i])) person[i] = tolower(person[i]);

0151}

0152TRANSL_RISC_BREG(ptr, (char *), rr->b3); memcpy(passwd, ptr, 12); passwd[ 12] = '\0'; if (ptr = (strchr(passwd, ' ")))

0153*ptr = V)'; breg_addr = rr->bl ; switch (chkpass(person, passwd))

0154{ case O: rr->rl = 0; break; case ENOENT: rr->rl = NOT.REGISTERED; break; case EACCES: rτ->rl = INVALID_PW; break; default: rr->rl = -1; break; } /* switch */ if «rr->rl != 0) II (rr->.2 =-- VALIDATE)) break; Page A-5

0155lock(qhdu->uq.priol ); if (rr->r2 == PRIM_LOGIN)

0156{ usrptr = (struct USRTBL *) _nk_dqh((struct LQHEAD *) qhdu,

0157AVA_L_Q); if (usrptr = 0)

0158{ un.ock(qhdu->uq.prio 1 ); syslog(LOGJΞRR- "E677: user queue full!"); rr->rl = 1; break;

0159} salι_it(salt); ptr = crypt(person, salt); strcpy(usφtr->cryptl, ptr); if (strlen(ρerson) > 8) ptr = crypi(&person[8], salt); strcpy(usτptr->cτypt2, ptr); usφtr->ltrb = breg_addr, lnk_qoh((struct LQHEAD *) qhdu, (struct LQHEAD *) usφtr, breg_addr); unlock(qhdu->uq.priol); rr->rl = 0; logged_on_dual_users++; break; } /* Listener connect */

0160/* this is a reconnect request - password is valid - insure entry in table */ breg_addr = rr->bl; qptr = qhdu; for (;;)

0161{ qptr = (struct USRTBL *) qptr->uq.fwd; if (qptr->uq.fwd = (unsigned long) qhdu)

0162{ qptr = 0; break;

0163} if (qptr->ltrb = breg_addr) break; } /* for */ if (qptr == 0)

0164{ rr->rl = 1; syslog(LOG_ERR, "E765: Reconnect failure for user <7. s", person); /* we are out of sync with Listener - dual decor user count may be wrong */

0165) else

0166{ rr->rl = 0;

0167) unlock(qhdu->uq.priol); break; case SECND.LOGIN: breg_addr = rr->b7; Page A-6

0168lock(qhdu->uq.priol); usφtr = (struct USRTBL *) lnk_dqh((struct LQHEAD *) qhdu, breg_addr); if (usφtr = 0)

0169{ breg_addr = rr->b7; qptr = qhdu; for (;;)

0170{ qpir = (struct USRTBL *) qptr->uq.fwd; if (qptr->uq.fwd == (unsigned long) qhdu) { qptr = 0; break;

0171) if (qptr->ltrb = breg_addr)

0172{ break;

0173) } /* for */ if (qptr == 0)

0174{ unlock(qhdu->uq.priol); rr->rl = 1; sys.og(LOG_ERR. "E766: Secondary level login failure"); if (logged_on_dual_users) logged_on_dual_users-- ; else syslog(LOG_ERR, "E891: ddcor user count corrupted"); break;

0175} else

0176{ unlock(qhdu->uq.ρriol); rr->rl = 0; break; } }

0177TRANSL_RISC_BREG(gcb, (struct GCB *), rr->bl); RISC_ADDR(tcb, (struct TCB *), gcb->g_ltcb); tcb = (stnict TCB *) ((char *) tcb - OFF.TCB); RISC_ADDR(breg_addr, (unsigned long), tcb->ι_ucbp); sprin_f(person. "%χ", gcb); ptr -s crypt(person, usφtr->cryptl); s_rcpy(usφtr->crypt3, ptr); lnk_qoh((stnιct LQHEAD *) qhdu, (struct LQHEAD *) usφtr, breg_addr); rτ->rl s 0; unlock(qhdu->uq.priol); break; case LOGOUT: breg_addr = rr->bl; lock(qhdu->uq.priol); qptr = qhdu; Page A- 7

0178for (;;)

0179{ qptr = (struct USRTBL *) qptr->uq.fwd; if (qptr->uq.fwd = (unsigned long) qhdu)

0180{ qptr = 0, break;

0181} if (qptr->ltrb = breg_addr) break; } /* for */ if (qptr = 0)

0182{ unlock(qhdu->uq .pπo 1 ); rr->rl = 1; syslog(LOG_ERR, "E767: Dual Decor logoff failure"); /* we are out of sync with Listener - dual decor user count may be wrong */ break;

0183} lnk_dqa((struct LQHEAD *) qptr); usφtr = qptr; strcpy(usφtr->cryptl, spaces); strcpy(usφtr->crypt2, spaces); strcpy(usφtr->crypt3, spaces); usφtr->ltrb = 0; lnk_qoh((struct LQHEAD *) qhdu, (struct LQHEAD *) qptr, AVAIL_Q); rτ->rl = 0; if (logged_on_dual_users) logged_on_dual_users- ; else syslog(LOG_ERR, "E892: ddcor user count corrupted"); unlock(qhdu->uq pnol); break; default: /* syslog( OG_DEBUG, "Login invalid parameter R2 = %04x". rr->r2);*/ rr->rl = 1; break; } /* switch r2 */

0184) /* if listener */ else rr->rl = PRTV VIOLATION; ) /* mc login */ * ***************

0185* mcl_sock_lm * 3727 - Return SOCK lm

0186**•_•*****_••**_•** mcl_sock_lrn(rr) struct RISC REGS *rr;

0187{ struct HDM *hdm_base; struct SCB *scb; struct GCB *gcb; struct LRT *lrt; Page A-8

0188struct RCT *rct; int i; long ssz; hdm_base = (struct HDM *) sys_rO;

0189RISC_ADDR(scb, (struct SCB *), hdm_base->h_scb);

0190RISC_ADDR(ssz, (long), scb->s_ssz); if (MCLng(rr)) /* check you are in ring 0 */ return; /*

0191* look for a free entry on the ddecor free queue */ if (rr->r2 = get_ddcor_rct(SOCK_ID))

0192{ rr->rl = SUCCESS.CODE; } /* if available Ink */ else

0193{ rr->rl = UNAVL_CODE; syslog(LOG_ERR, "El 181: SOCK No available LRN");

0194} } /* mcl_sock_lm */

0195Page A-9

0196******************************************************************************

0197Host System Security Verification Routines

0198****************************************************************************** static mt getgrouphst(char *user); stauc void setresult(ιnt "result, int scantype, int access); int user_access(char *object, char *usemame); static int geuclmfodnt scantype, struct acl * aclbuffer, struct stat * statbuff); get_access(char *, chart], int); get_user( struct IRB *, struct LRB *. char[]); void get_acl_qhead(void); int chkpass(char *. char *); void salt_iι(char *); struct HDM *hdm_base; struct SCB *scb; struct MQI *saq; struct MQI *pswd_in, *pswd_out; struct PSWD_Q *pswd_queue; struct USRTBL *qhdu; char group_path[MAXPATHLEN + 1]; int Uid; extern int vm_vιew, dps6_uvah; extern char *base, *sys_rO; stauc gιd_ι Gidseisize, Gιdset[NGROUPS_MAX]; stauc char *accesses[] = { " — ", "--x", "-w-", "-wx",

0199V-", "r-x", "rw-", "rwx"}; static int ιs_in_group(gid_t groupid); extern char *crypt();

0200^**» ************

0201* getgrouplist *

0202***********•***/ static int getgrouplist(char ""user)

0203{ int re; struct passwd *pwent; pwent = getρwnam(user); if (pwent == NULL) Page A- 10

0204return (-1); Uid = pwent->pw_uid; if (initgroups(user, pwent->pw_gid) != 0) return (-1); Gidsetsize = rc = getgroups(sizeof(Gidset) / sizeof(gid_t), Gidset); /* syslog(LOG_INFO, "1363: Groupset was %d members", Gidsetsize); */ if (rc == -l) return (-1); else return (0); } /* getgrouplist */

0205/_•*•*_•**•****

0206* setresult *

0207•*•***•*****/ static void setresult(int *result, int scantype, int access)

0208{ access &amp;= 07; switch (scantype)

0209{ case ACC_PERMIT:

0210•result 1= access; break; case ACC_SPECIFY:

0211^♦result = access; break; case ACC_DENY:

0212^♦result &amp;= -access; break;

0213} } /* setresult */

0214/•****** *******

0215* user_access *

0216************* i^ int user_access(char *object, char *username)

0217{ int rc, ACLSize, sizeok; struct acl *aclbuffer; int finalaccess; struct stat statbuffer; finalaccess = 0;

0218ACLSize = ACL_SIZ; /* normal size */ aclbuffer = (struct acl *) malloc(ACLSize); if (aclbuffer = NULL)

0219{ return (finalaccess); } /* NULL buffer */ do

0220{ sizeok = 0; Page A- 11

0221rc = statacKobject, STX_NORMAL, aclbuffer, ACLSize); if (rc '= 0 &amp;&amp; emio == ENOSPC)

0222{ sizeok = 1 ,

0223ACLSize = *(ιnt *) aclbuffer; free(aclbuffer); aclbuffer = malloc(ACLSιze); if (aclbuffer = NULL)

0224{ return (finalaccess),

0225}

0226while (sizeok '= 0); ιf (rc = 0)

0227{ int thisaccess,

0228/* syslog(LOG_INFO, "1364: User is %s", usemame);*/ rc = statfobjcct, &amp;statbuffer); if (rc '= 0 II getgrouplisUusemame) != 0)

0229{ free(aclbuffer), return (finalaccess);

0230} thisaccess = getaclιnfo(ACC_PERM_T, aclbuffer, &amp;statbuffer); /* syslog(LOG_INFO, "1365. Scan for permit results: *7.o", thisaccess);*/ setresultf&amp;finalaccess, ACC_PERMIT, thisaccess); thisaccess = getaclιnfo(ACC_SPECIFY, aclbuffer. &amp;statbuffer); /* syslog(LOG_INFO, "1366: Scan for specify results: %o", thisaccess);*/ if ((thisaccess &amp; 010) = 0) setresulU&amp;finalaccess, ACC_SPECIFY, thisaccess), thisaccess = getaclιnfo(ACC_DENY, aclbuffer. &amp;statbuffer), /* syslog(LOG_INFO, "1367: Scan for deny results: "7. o", thisaccess);*/ setresulι(&amp;finalaccess, ACC_DENY, -thisaccess);

0231} free(aclbuffer); return (finalaccess), } /* user_access */

0232/*** ***********

0233* is_ιn_group *

0234**•**•_••*•**_•*/ stauc int ιs_ιn_group(gιd_t grouptd)

02351 int r, for (i = 0; ι &lt; Gidsetsize; ι++) if (Gidset[ι] = groupid) return (1); return (0); Page A- ?2

0236} /* is_in_group */

0237/*************

0238* getaclinfo *

0239********* ****^ static int getaclinfo(int scantype, struct acl * aclbuffer, struct stat * statbuff)

0240{ int gobbled; int result; struct acLentry *aep; struct ace_id *aip; switch (scantype)

0241{ case ACC.PERMIT: result = aclbuffer->o_access; if (is_in_group(sιatbuff->st_gid)) result = aclbuffer->g_access; if (Uid == statbuff->st_uid) result = aclbuffer->u_access; break; case ACC.SPECIFY: result = 010; break; case ACC_DENY: result = 7; break;

0242} /* syslogCLOGJNFO, "1368: ac.Jen=9.d,u=%o,g=7.o,o=%o", ac.buffer->acl_len, aclbuffer->u_access, aclbuffer->g_access, aclbuffer->o_access);*/ gobbled = ACL_SIZ; aep = &aclbuffer->acl_ext[0]; while (aclbuffer->acljen > gobbled)

0243{ int nibbled; int userseen; int thisisone; thisisone = 1 ; if (aep->ace_type != scantype)

0244{ gobbled += aep->ace_len; aep = (struct acLentry *) ((char *) aclbuffer + gobbled); continue;

0245} /* syslog(LOG_INFO, "1369: aceJen=%d,%o,9_s", aep->ace_len, aep->ace_access,

0246(aep->ace_type == ACC_DENY) ? "deny" : ((aep->ace_type = ACC_PERM-T) ? "permit" : "specify"));*/ Page A- 13

0247gobbled += ACE_SIZ; nibbled = ACE.SIZ; aip = &aep->acejd[0]; userseen = 0; while (aep->ace Jen > nibbled)

0248{ int idno; if (aip->id_type == ACEID_USER) userseen++; /* syslogCLOGJNFO, "1370: %s:",

0249(aip->id_type = ACEIDJJSER) ? "u" : "g");*/ for (idno = 0; idno < (aip->idjen - ID_SIZ) / sizeof(aip->id_data); idno++) /* syslogCLOG_INFO, "1371: %ld". aip->id_data[0]);*/ if (aip->id_type = ACEID_USER && Uid != aip->id_datat0]) thisisone = 0; if (aip->id ype = ACEID_GROUP

0250&& is_in_group(aip->id_data[0]) == 0) thisisone = 0; gobbled += aip->id Jen; nibbled += aip->idjen; aip = (struct ace_id *) ((char *) aep + nibbled);

0251} if (userseen > 1)

0252{ thisisone = 0; /* syslogCLOG INFO, "1372: Invalid - more than one user");*/

0253} if (thisisone) setresulK&result, scantype, aep->ace_access); aep = (struct acLentry *) ((char *) aclbuffer + gobbled);

0254} return (result); } /* get_acl_info */ ***_•*_•**•*•**

0255* get_access *

0256*•*********•* int get_access(char *pp, char person[], int type)

0257{ int i; char *path, replaced; char cmnd[128]; int access, dirfail; path = pp; access = 01; dirfail = 0; do

0258[ if (access &amp; 01)

0259{ replaced = *(++pp); Page A- 14

0260*pp = 0; access = user_access(path, person);

0261*pp = replaced; pp = strchrCpp, 7);

0262} else

0263{ pp = NULL; dirfail = 1;

0264} } while (pp &amp;&amp; *pp); if (dirfail = 0 &amp;&amp; path{strlen(path) - 1] != 7)

0265{ if (type = LK_FILE) access = user_access(patb, person); } if (dirfail) access = -1; return (access); } /* get_access */ *_•*********

0266* get_user *

0267***********/

0268/*

0269* validate user as "trusted" (by group-id) or having a Host pseudo-login */ int get_user(struct IRB * irb, struct LRB * iorb, char *person)

0270{ struct UCB *ucb; struct LQHEAD *prev; char tempi 130]; struct USRTBL *unxt; struct GCB *gcb; struct TCB *tcb; struct FCB *fcb; struct FDB *fdb; static int groups, end_of_ string, i, count; static char *bytes_tran; char groupjd[130], account[130], gφ_buff[130];

0271/*

0272* if this is a Listener logged in user check USRTBL. for other groups

0273* check the GROUPS file (if it exists) to establish the group to Uid

0274* association, an entry in the file of the form "ID *" associates the

0275* group ID to whatever user is specified in the UCB. entries of the form

0276* "ID HOST-user" override any userid specified in the UCB - Host-user is

0277* always used, the GROUPS file is never checked for Listener users.

0278* note: if a group doesn't have a lead task, reject it (as far as we

0279* know, this only applies to SS, since all other groups should have lead tasks).

0280*/ Page A- 15

0281RISC_ADDR(gcb, (struct GCB *), irb->i_gcb); RISC_ADDR(tcb, (struct TCB *), gcb->gjtcb); if C(gcb->g_ltcb[0] 1 gcb->gjtcb[l]) — 0)

0282{ syslogCLOG_INFO, "1631: access denied for $S task group"); return 0;

0283} tcb = (struct TCB *) ((char *) tcb - OFF TCB); RISC_ADDR(fcb, (struct FCB *), tcb->t_iuip); RISC_ADDR(fdb. (struct FDB *). fcb->c dbp); if (fdb->d_ind2 & md_Isn)

0284{

0285RlSC_ADDR(ucb, (struct UCB *), tcb->t_ucbp); lock(qbdu->uq .prio 1 ); unxt = (struct USRTBL *) lnk_fιndq((struct LQHEAD *) qhdu, ucb, &prev); if (strlen(person) > 8) i = 8; else i = 0; sprintfdemp, "%x", gcb); if (!(unxt))

0286{ syslog(LOG_INFO,

0287"1497: access denied for %s: user not registered", person); unlock(qhdu->uq.priol); return (0); /* user not Host registered */

0288} if ((strcmp(crypt(person, unxt->crypιl), unxt->cτyptl) != 0) II (stτcmp(crypt(&person[i], unxt->crypt2). unxt->crypt2) != 0) II (strcmp(crypt(temρ, unxt->crypt3), unxi->crypt3) != 0))

0289{ syslogCLOGJNFO,

0290"1498: access denied for %s: user name changed", person); unlock(qhdu->uq.pno 1 ); return (0); } unlock(qhdu->uq.priol); return (1); /* appears valid */

0291if (group_path[0] != 0)

0292{ do groups = (int) fopen(group_path, "r"); while ((groups &lt; 0) &amp;&amp; (ermo = EINTR)); if (groups &lt; 0) return (0); i = 0; for (;;)

0293{ do

0294{ ermo = 0; Page A- 16

0295bytes_tran = fgets(gφ_buff, 129, (FILE *) groups);

0296) while ((bytes.tran = NULL) && Cerrno == EINTR)); if (bytes.tran == NULL) break; end_of_string = s-rcspn(gφ_buff, "\n"); if (!Cend_of_string)) continue; /* skip null lines */ if ^-.bufflO^ '*') continue; /* skip comments */ gφ_buffIend_of_string] = V)'; if ((count = sscanf(gφ_buff, "%s %s%130c", group d, account, temp)) > 0)

0297{ if ((strlen(groupjd) != 2) II CstrcmpCgroupJd, "$L") == 0) II CstrcmpCgroupJd, "$S") == 0) II (count < 2) II (strlen(account) > 12))

0298{ syslogCLOG_ERR,

0299"E658: Invalid GROUP entr : %s", gφ_buff); continue;

0300} if (me cmpCgroupJd, &gcb->g_name, 2) = 0)

0301{ if (strcmpCaccount, "*") = 0)

0302{ i = l ; break;

0303} strcpyCperson. account); for (i = 0; i &lt; strlen(person); i++)

0304{ if Cisupper(person[i])) person[i] = tolowerCpersonfi]);

0305} i = 1; break; } } } /* for */ fcloseCCFILE *) groups); if &lt;!(_)) syslogCLOG_INFO,

0306"1499: access denied for %s: user not registered", person); return (i); ) syslogCLOG_INFO,

0307"1500: access denied for %$: user not registered", person); return CO); } /* get_user */

0308/****************

0309* get_acl_qhead *

0310**************** Page A- 17

0311/*

0312* set up queue header pointer for logged on users (qhdu) */ void get_acl_qhead(void)

0313{ hdm_base = (struct HDM *) sys_rO;

0314RISC_ADDR(scb, (struct SCB *), hdm_base->h_scb);

0315RISC_ADDR(saq, (struct MQI *), scb->s_saq); qhdu = (struct USRTBL *) (saq + 1); return; } /* get_acl_qheads */ **********

0316* chkpass *

0317*•**•*•*•*/ int chkpass(char *user, char *passwd)

0318{ strcpy(pswd_queue->user, user); strcpy(pswd_queue->passwd, passwd); mqi_qot(pswd_out, (struct MQLLINKS *) pswd_queue); pswd_queue = (struct PSWD_Q *) mqi_dqh(pswd_in); return (pswd_queue->valid); } /* chkpass */ *****•*•**

0319* saltjt *

0320••*_•*_•****

0321/*

0322* create a random "salt" for crypt - upper and lower alpha only */ void salt JtCchar *salt)

0323{ int t, r, t = time(0); r = t % 52; if (r > 25) salt[0] = 'a' + r - 26; else salt[0] = 'A' + r; r = (((t+ r) / ll) * 7) 52; if (r > 25) salt[l] = 'a' + r - 26; else salt[l] = 'A' + r; salt[2] = Λ0'; return; Page A- 18

0324) I* salt Jt */

0325Page A- 19

0326Special User Table Structure Templates struct LQHEAD

0327{

0328/* Note that in a header priol may be a semaphore */ unsigned long priol; /* qhdr/qfrm priority */ unsigned long fwd; /* qhdr/qfrm forward link */ unsigned long bwd; /* qhdr/qfrm backward link */

0329struct USRTBL

0330{ struct LQHEAD uq; /* uses UCB or LTRB address for priority */ unsigned long ltrb; char crypιl[14] char cτypt2[14] char crypt3[14]

0331}; struct PSWTLQ struct MQLLINKS pswd nqi; int valid; char user[14); char pass wd[ 14];

0332Page B-l APPENDIX B

DUAL DECOR COMMANDS

03341. The CPX command is a dual decor command which copies files between the emulated system and host system. The CPX Command Format is as follows:

0335CPX source_pathname destination_pathname [ctl_args]

0336Arguments: sourcejjathname

0337This argument corresponds to the pathname of the file to be copied. Host pathnames must be enclosed in double quotes, must be complete pathnames and must start with x: or X:. If the pathname does not start with x:, it is assumed to be an emulated system file. destination_pathname

0338This argument corresponds to the pathname of the file that is to be copied to. The same applies to the naming of pathnames. ctl_args

0339None or any of the following control arguments may be used: -BINARY I -B I -TEXT I -T to specify whether the file being copied is copied as a binary file or a text file. -CLONE clone j)athname I -SEQ I -S_R

0340Sets file attributes of a file being created on an emulated system by using one of the three options.

0341-CLONE clone_pathname I -C clone_pathname

0342Creates a file using the attributes of the emulated system file specified by clone_pathname. -SEQ

0343Creates an emulated system UFAS sequential file with 512 byte sectors. -S_R

0344Creates an emulated system UFAS string-relative file with 512 byte sectors. Default: -S_R (string relative). Page B-2

-DELETE I -DL

0346Deletes the source file after the copy is complete. -LIST I -LS

0347Issues confirmation messages.

03482. The LK command is a dual decor command which creates links between emulated system files and host files or creates links to named pipes. The LK Command Format is as follows:

0349LK GCOSNAME "X:xpath" [ -BINARY I -TEXT] [-FILE I -PIPE]

0350Arguments:

0351-BINARY I -BIN I -B I -TEXT | -TXT | -T

0352Specifies whether the pipe or link being created is a binary pipe or link or a text pipe or line.

0353Default. Binary file, xpath

0354Designates a host pathname for the link. -FILE

0355Specifies a link to a file. Do not use with -PIPE. GCOSNAME

0356Designates the emulated system name of the link. -PIPE

0357Specifies a named pipe. Do not us with -FILE.

0358Page B-3

03593. The XSH command is a dual decor command which allows a user to run host commands from an emulated system terminal. The XSH Command Format is as follows:

0360XSH ["xcommand [&amp;]"]

0361Arguments: ^Hxcommand[&amp;]"

0362Designates a host command that user wants to execute.

0363&amp;

0364Designates running command in background (asynchronously).

0365It will be apparent to those skilled in the art that many changes may be made to the preferred embodiment of the present invention.

0366While in accordance with the provisions and statutes there has been illustrated and described the best form of the invention, certain changes may be made without departing from the spirit of the invention as set forth in the appended claims and that in some cases, certain features of the invention may be used to advantage without a corresponding use of other features.

0367What is claimed is: