|
HP OpenVMS Systems Documentation |
|
OpenVMS Programming Concepts Manual
Because the OpenVMS system services codes are all positive numbers and
because the call to a privileged routine is initially handled by the
system service dispatcher, you should assign negative code numbers to
identify your privileged routines so they do not conflict with system
services identification codes.
On Alpha systems, in addition to the routines that perform privileged
functions, you must also include a PLV in your source file. However, on
Alpha systems, you list the privileged routines by name in the PLV. You
do not need to create a dispatch routine that transfers control to the
routine; the routine is identified by a special code.
On Alpha systems, the PLV contains a list of the actual addresses of the privileged routines. The image activator creates the dispatch routines. Figure 31-3 illustrates the linkage for a privileged routine on Alpha systems. Figure 31-3 Linkage for a Privileged Routine After Image Activation 
Table 31-2 describes the components of the privileged library vector on Alpha systems.
Example 31-3 illustrates how to create a PLV on Alpha systems.
31.4.2 Declaring Privileged Routines as Universal Symbols Using Symbol Vectors on Alpha SystemsOn Alpha systems, you declare a user-written system service to be a universal symbol by using the symbol vector mechanism. (See the OpenVMS Linker Utility Manual for more information about creating symbol vectors.) However, because user-written system services must be accessed by using the privileged library vector (PLV), you must specify an alias for the user-written system service. Use the following syntax for the SYMBOL_VECTOR= option to specify an alias that can be universal:
In a privileged shareable image, calls from within the image that use the alias name result in a fixup and subsequent vectoring through the PLV, which results in a mode change. Calls from within the shareable image that use the internal name are made in the caller's mode. (Calls from external images always result in a fixup.) The linker command procedures and options file shown in Example 31-4 illustrate how to declare universal symbols in an Alpha system privileged shareable image.
Chapter 32
|
| BATCH | All attempts at access made by batch jobs |
| NETWORK | All attempts at access made across the network |
| INTERACTIVE | All attempts at access made by interactive processes |
| LOCAL | All attempts at access made by users logged in at local terminals |
| DIALUP | All attempts at access made by users logged in at dialup terminals |
| REMOTE | All attempts at access made by users logged in on a network |
Depending on the environment in which the process is operating, the
system includes one or more of these identifiers when creating the
process rights list.
32.2.4 UIC Identifiers
Each UIC identifier is unique and represents a system user. By default, when an account is created, its UIC is associated with the account's user name generating an identifier value. When the high-order bit <31> of the identifier value is zero, the value identifies a UIC format identifier as shown in Figure 32-2.
Figure 32-2 UIC Identifier Format
Bits <27:16> and <15:0> designate a group field and member
field. Group numbers range from 1 through 16,382; member numbers range
from 0 through 65,534.
32.2.5 Facility Identifiers
Facility-specific rights identifiers allow a range of unique binary identifier values to be reserved for a particular software product or application. Compare the format of facility-specific identifiers with the format of general identifiers and UIC identifiers, as shown in Section 32.2.1. The system normally determines the binary values of general identifiers when the system manager creates them; the system manager determines the binary values of UIC identifiers.
Figure 32-3 shows the facility-specific identifiers.
Figure 32-3 Facility-Specific Identifiers
The binary value of a facility-specific identifier is determined at the time the application is designed. The facility number of the identifier must match the facility number the application has chosen for its condition and message codes. The remaining 16-bit facility-specific value may be assigned at will by the application designer. By reserving specific binary identifier values, the application designer may code fixed identifier values into an application's calls to $CHECK_PRIVILEGE, $GRANT_ID, and so forth. It avoids the added complexity of first having to translate an identifier name to binary with $ASCTOID.
An application can choose to register the identifiers in the rights database or not, depending on its needs. If the identifiers are registered, they are visible to the system manager who may grant them to users. In any case, they will be displayed properly if they appear on access control lists. If they are not registered, they will remain invisible to the system manager. Unregistered identifiers that appear on access control lists are displayed as a hexadecimal value.
To register its identifiers, the installation procedure of the application must run a program that enters the identifiers into the rights database using the $ADD_IDENT service. You cannot specify facility-specific identifier values to AUTHORIZE with the ADD/IDENTIFIER command.
Typically, facility-specific identifiers serve to extend the OpenVMS privilege mechanism for an application. For example, consider a database manager that includes a function to allow appropriately privileged users to modify a schema. Access to this function could be controlled through a facility-specific identifier named, for example, DBM$MOD_SCHEMA. The system manager grants the identifier to authorized persons using the AUTHORIZE command GRANT/ID. The database services that modify schemas use the $CHECK_PRIVILEGE service to check that the caller holds the identifier.
In another example, a privileged program run by users when they log in
uses $GRANT_ID to grant the user certain facility-specific identifiers,
depending on conditions determined by the program; for example, time of
day or access port name. These identifiers can be placed on the ACLs of
files to control file access, or they might be checked by other
software with $CHECK_PRIVILEGE.
32.2.6 Identifier Attributes
An identifier has attributes associated with it in the rights database. The process rights list includes the attributes of any identifiers that the process holds.
The use of rights identifiers can be extended with the following identifier attribute keywords:
| DYNAMIC | Allows unprivileged holders of an identifier to add or remove the identifier from the process rights list using the DCL SET RIGHTS command. Conversely, an unprivileged user who does not have the attribute cannot modify the identifier. |
| HOLDER_HIDDEN | Prevents someone from using the SYS$FIND_HOLDER system service to get a list of users who hold an identifier, unless that person holds the identifier. |
| NAME_HIDDEN | Allows only the holders of an identifier to have it translated, either from binary to ASCII or from ASCII to binary. |
| NO_ACCESS | Specifies that the identifier does not affect the access rights of the user holding the identifier. |
| RESOURCE | Allows the holder of an identifier to charge resources, such as disk blocks, to an identifier. |
| SUBSYSTEM | Allows holders of the identifier to create and maintain protected subsystems. |
The following example demonstrates the advantages of defining an identifier and holders for a project.
The Physics department of a school has a common library with an associated disk quota on the system. In order to use the Resource attribute, you must enable disk quotas and establish a quota file entry using the SYSMAN utility. You want to allow the faculty members to charge disk quota that they use in conjunction with the library to the identifier PHYSICS associated with the common library and to prevent the students from charging resources to that identifier.
$ MCR SYSMAN SYSMAN> DISKQUOTA CREATE/DEVICE=DKB0: SYSMAN> DISKQUOTA MODIFY/DEVICE=DKB0: PHYSICS /PERMQUOTA=150000 - _SYSMAN> /OVERDRAFT=5000 SYSMAN> EXIT |
If you specify the Resource attribute for identifier FRED, he can charge disk resources to the PHYSICS identifier; if you do not specify the Resource attribute for identifier GEORGE, he will not inherit the Resource attribute associated with the identifier PHYSICS and cannot charge disk resources to the PHYSICS identifier. The following input file, USERLIST.DAT, contains valid UIC identifiers of students and faculty members:
FRED NORESOURCE GEORGE RESOURCE NANCY NORESOURCE HAROLD RESOURCE SUSAN RESOURCE CHERYL NORESOURCE MARVIN NORESOURCE |
The following program reads USERLIST.DAT and associates the UIC identifiers with the identifier PHYSICS:
#include <stdio.h>
#include <descrip.h>
#include <ssdef.h>
#include <lib$routines.h>
#include <kgbdef.h>
#include <nam.h>
#include <string.h>
#include <stdlib.h>
#define IDENT_LEN 31
#define NO_ATTR 0
#define RESOURCE 1
#define NORESOURCE 0
unsigned int sys$asctoid(),
sys$add_ident(),
sys$add_holder(),
sys$idtoasc(),
convert_id( struct dsc$descriptor_s, unsigned int );
void add_holder( unsigned int, unsigned int, unsigned int);
struct {
unsigned int uic;
unsigned int terminator;
}holder;
static char ascii_ident[IDENT_LEN],
abuffer[IDENT_LEN],
dirbuf[NAM$C_MAXRSS],
targbuf[IDENT_LEN];
$DESCRIPTOR(target,targbuf);
unsigned int status;
main() {
FILE *ptr;
char attr[11];
unsigned int owner_uic, attrib, resid, bin_id;
$DESCRIPTOR(dirspec,dirbuf);
$DESCRIPTOR(aident, abuffer);
printf("\nEnter directory spec: ");
gets(dirbuf);
dirspec.dsc$w_length = strlen(dirbuf);
printf("\nEnter its owner identifier: ");
gets(targbuf);
target.dsc$w_length = strlen(targbuf);
/* Add target identifier WITH resource attribute to the rights database */
attrib = KGB$M_RESOURCE;
status = sys$add_ident( &target, 0, attrib, &resid);
if((status & 1) != SS$_NORMAL)
lib$signal( status );
else
printf("\nAdding identifier %s to rights database...\n",
target.dsc$a_pointer);
/* Create the common directory with the target id as owner */
owner_uic = resid;
status = lib$create_dir( &dirspec, &owner_uic, 0, 0);
if((status & 1) != SS$_NORMAL)
lib$signal( status );
else
printf("Creating the directory %s...\n",dirspec.dsc$a_pointer);
/* Open an input file of UIC identifiers and attribute types */
if((ptr = fopen("USERLIST.DAT","r")) == NULL) {
perror("OPEN");
exit(EXIT_FAILURE);
}
/* Read the input file of UIC identifiers */
while((fscanf(ptr,"%s %s\n",abuffer,attr)) != EOF) {
aident.dsc$w_length = strlen(abuffer);
attrib = (strcmp(attr,"RESOURCE")) == 0 ? KGB$M_RESOURCE : NO_ATTR;
bin_id = convert_id( aident, attrib);
add_holder( bin_id, resid, attrib );
}
/* Close the input file */
fclose(ptr);
}
unsigned int convert_id( struct dsc$descriptor_s uic_id,
unsigned int attr ) {
unsigned int bin_id;
status = sys$asctoid(&uic_id, &bin_id, &attr);
if((status & 1) != SS$_NORMAL)
lib$signal( status );
else {
printf("Converting identifier %s to binary format...\n",
uic_id.dsc$a_pointer);
return bin_id;
}
}
void add_holder( unsigned int bin_id, unsigned int resid,
unsigned int attrib ) {
int i;
$DESCRIPTOR(nambuf, ascii_ident);
holder.uic = bin_id;
holder.terminator = 0;
status = sys$add_holder( resid, &holder, attrib);
if((status & 1) != SS$_NORMAL)
lib$signal( status );
else {
status = sys$idtoasc(bin_id, 0, &nambuf, 0, 0, 0);
if((status & 1) != SS$_NORMAL)
lib$signal( status );
/* Remove padding */
nambuf.dsc$w_length = strlen(ascii_ident);
for(i=0;i < nambuf.dsc$w_length + 1; i++)
if (ascii_ident[i] == 0x20)
ascii_ident[i] = '\0';
printf("\nAdding holder %s to target identifier %s...\n", \
nambuf.dsc$a_pointer,target.dsc$a_pointer);
}
}
|
| Previous | Next | Contents | Index |
