Operating System - OpenVMS
1748036 Members
4950 Online
108757 Solutions
New Discussion юеВ

Re: Wrong image name identified in IMGNAME error message

 
Richard J Maher
Trusted Contributor

Wrong image name identified in IMGNAME error message

Hi,

If after running the attached DCL command file, (please also see brief documentation at EOF) you were to define LIBRTL to point to a non-INSTALLed copy in your local directory, before entering: -

$ run test_dir

You would be greeted with the following message: -

%DCL-W-ACTIMAGE, error activating image DIR_WATCH_EXEC
-CLI-E-IMGNAME, image file TIER3$DKA200:[SYS0.SYSCOMMON.][SYSLIB]DIR_WATCH_EXEC.EXE
-SYSTEM-F-PRIVINSTALL, shareable images must be installed to run privileged image

I, personally, think that's wrong and it should be reporting the error on LIBRTL as DIR_WATCH_EXEC is happily installed and doing all it has to.

FYI.

Cheers Richard

+
--------------------------------------------------------------------------------
WAITFR_FILE

Monitor an on-disk directory until the user-specified file has
been created. This service completes asynchronously.

For additional information about system service completion,
refer to the Synchronize ($SYNCH) service

--------------------------------------------------------------------------------
FORMAT SYS$WAITFR_FILE [efn] ,filespec ,resultant-filespec
[,iosb] [,astadr] [,astprm]

--------------------------------------------------------------------------------
ARGUMENTS efn
OpenVMS usage: ef_number
type: longword (unsigned)
access: read only
mechanism: by value

Event flag that SYS$WAITFR_FILE is to set once this service
detects that the user-specified file has been created. The efn
argument is a longword value containing the number of the event
flag; however, SYS$WAITFR_FILE uses only the low-order byte. If
you do not specify efn, event flag 0 is set.

When SYS$WAITFR_FILE begins execution, it clears the specified
event flag or event flag 0 if efn was not specified.

filespec
VMS usage: char_string
type: character-coded text
access: read only
mechanism: by descriptor--fixed length string descriptor

File specification, which may not contain wildcards, that
SYS$WAITFR_FILE uses to search for the desired file. The
filespec argument is the address of a descriptor pointing to
the file specification. The maximum length of the file
specification is 255 bytes.

Additionally, the file specification may not contain a search
list logical name, a node specification or a device name that
refers to a device other than a disk device.

SYS$WAITFR_FILE uses RMS to parse the filespec argument. If RMS
is unable to parse the file specification then SYS$WAITFR_FILE
will place the secondary RMS error status (STV) into the first
longword of the iosb argument.











+
resultant-filespec

OpenVMS usage: char_string
type: character string
access: modify
mechanism: by descriptor--fixed length string descriptor

Resultant file specification that SYS$WAITFR_FILE returns when
it has successfully parsed the specification in the filespec
argument. All concealed logical names will have been translated
in this expanded file specification.

iosb

OpenVMS usage: io_status_block
type: quadword (unsigned)
access: write only
mechanism: by 32-bit reference

I/O status block that is to receive the final completion status.
The iosb argument is the 32-bit address of the quadword I/O
status block.

SYS$WAITFR_FILE sets the quadword to 0 upon request initiation.
Upon request completion, a condition value is returned to the
first longword; the second longword is reserved for future use.

Though this argument is optional, TIER3 strongly recommends that
you specify it, for the following reasons:

. If you are using an event flag to signal the completion of the
service, you can test the I/O status block for a condition value
to be sure that the event flag was not set by an event other
than service completion.

. If you are using the $SYNCH service to synchronize completion
of the service, the I/O status block is a required argument for
$SYNCH.

. The condition value returned in R0 and the condition value
returned in the I/O status block provide information about
different aspects of the call to the SYS$WAITFR_FILE service.
The condition value returned in R0 gives you information about
the success or failure of the service call itself; the condition
value returned in the I/O status block gives you information
about the success or failure of the service operation.
Therefore, to accurately assess the success or failure of the
call to SYS$WAITFR_FILE, you must check the condition values
returned in both R0 and the I/O status block.














































+
astadr

OpenVMS usage: ast_procedure
type: procedure value
access: call without stack unwinding
mechanism: by 32-bit reference

AST service routine to be executed when SYS$WAITFR_FILE
completes. The astadr argument is the 32-bit address of this
routine.

If you specify astadr, the AST routine executes at user mode
regardless of the access mode of the caller of the service.

astprm

OpenVMS usage: user_arg
type: longword (unsigned)
access: read only
mechanism: by value

AST parameter to be passed to the AST service routine specified
by the astadr argument. The astprm argument is the longword
parameter.

--------------------------------------------------------------------------------
DESCRIPTION
Control returns to your program immediately following successful
completion of this service. Once SYS$WAITFR_FILE detects that
the file specified by filespec has been created, this service
will inform your program by setting the event flag specified by
efn and, if specified, delivering the AST.

For each VMS Process, there can only be one SYS$WAITFR_FILE
service 'active' at any given time. Therefore it is not
currently possible to implement OR type waits with
SYS$WAITFR_FILE. That is, you can not choose to wait for this
file OR that file.

Required Privileges

You must have read access to the disk and directory that you are
monitoring.

Related Services

SYS$WAITFR_FILE_CANCEL
















































+
--------------------------------------------------------------------------------
CONDITION SS$_NORMAL The service completed successfully. The
VALUES directory watch has been initiated.
RETURNED SS$_INSFARG Insufficient call arguments specified.
Although astadr and astprm arguments are
optional they must still be specified as
zero.
SS$_ABORT A call to SYS$WAITFR_FILE is already
active. Only one call to this service
per process, is permitted at any given
time. Review your code or cancel the
outstanding directory watch with
SYS$WAITFR_FILE_CANCEL.
SS$_ACCVIO Filespec could not be read by the caller
or either the resultant-filespec or iosb
arguments could not be written to by the
caller.
SS$_BADPARAM One or more of the following conditions
is true: -
. filespec is longer than 255 characters
. filespec contained a wildcard * or %
. filespec contained a node name
. filespec contained a searchlist
SS$_UNSUPPORTED No FID could be obtained for the
directory specification or the specified
device is not a disk device.

Any errors returned by the following services:-
SYS$PARSE
SYS$ASSIGN
SYS$GETDVIW
SYS$ENQ
LIB$GET_EF

--------------------------------------------------------------------------------
CONDITION SS$_NORMAL The file that you have been waiting for
VALUES has been created.
RETURNED SS$_CANCEL The wait was cancelled by a call to
IN THE I/O SYS$WAITFR_FILE_CANCEL
STATUS fab$l_stv Secondary RMS error status. This will
BLOCK only occur if SYS$WAITFR_FILE failed
while attempting to call SYS$PARSE.

--------------------------------------------------------------------------------



+
--------------------------------------------------------------------------------
WAITFR_FILE_CANCEL

The cancel wait for file service will abort a file watch that
was previously set in motion by a call to SYS$WAITFR_FILE.

--------------------------------------------------------------------------------
FORMAT SYS$WAITFR_FILE_CANCEL

--------------------------------------------------------------------------------
ARGUMENTS
None.

--------------------------------------------------------------------------------
DESCRIPTION The cancel file wait service is used to prematurely terminate a
previous call to SYS$WAITFR_FILE.

SYS$WAITFR_FILE_CANCEL relinquishes all system resources
obtained by SYS$WAITFR_FILE, sets the specified event flag, and
delivers the AST to the calling process, if one was requested.

In order to identify the abnormal termination of the wait for
file service SYS$WAITFR_FILE_CANCEL sets the IOSB status to
SS$_CANCEL.

It is not a requirement of SYS$WAITFR_FILE that this routine be
called. The equivalent processing, except for AST delivery and
event flag setting is implied at image exit.

Required Privileges

None.

Related Services

SYS$WAITFR_FILE

--------------------------------------------------------------------------------
CONDITION SS$_NORMAL The service completed successfully.
VALUES
RETURNED

14 REPLIES 14
Richard J Maher
Trusted Contributor

Re: Wrong image name identified in IMGNAME error message

Hi,

But I hasten to add, maybe dir_watch_exec should be linked with /PROTECT and shouldn't be calling out to LIBRTL at all? Maybe the LIB$*_EF calls should be moved to the dir_watch_user module? Who knows?

But then John says that MOVC3 translates to an OTS$ lib call? So should we code around that?

It's time to refer to "Them" rules. . . Doh!

Cheers Richard
Phil.Howell
Honored Contributor

Re: Wrong image name identified in IMGNAME error message

Opinion only - I disagree.
The error message isn't caused by librtl or a call to librtl, it is the image activator checking your image and finding problems.
You may think that "DIR_WATCH_EXEC is happily installed and doing all it has to",
but vms thinks that "I have a privileged image that may try to get around security restrictions by calling an untrusted image".
If you define your librtl as an executive logical name, then the vms image activator will allow dir_watch_exe to run.
(you probably knew this already)
Phil

Richard J Maher
Trusted Contributor

Re: Wrong image name identified in IMGNAME error message

Phil,

Can you please include the output from the testing that you conducted on this, as I appear to get different results from you? Especially the bit where you have an unINSTALLED LIBRTL (albeit pointed to by a /SYS/EXEC logical name) being activated when called from a UWSS. I, for one, would really like to see that.

Please see the "User Action" bit below. If the local copy of LIBRTL is in fact installed then everything is peachy. So once again I submit to the panel that LIBRTL is the image that needs to be installed so LIBRTL is the image that needs to be in the error message.

As to the reason why the image activator is happy to pursue a non /sys/exec logical name for LIBRTL when it appears to bypass them for others is, at present, a mystery to me. The good news is, regardless of logical name resolution, VMS appears to insist on all images being installed. This is the mut's nuts!

Cheers Richard


PRIVINSTALL, shareable images must be installed to run privileged
image

Facility: SYSTEM, System Services

Explanation: Two possible reasons for this error are:

o An attempt was made to run a privileged image with
uninstalled shareable images.

o An uninstalled shareable image was referenced when the main
program was installed with the /EXECUTE_ONLY qualifier.


User Action: Ask the system manager to install all shareable images used by
executable images.
John Gillings
Honored Contributor

Re: Wrong image name identified in IMGNAME error message

Richard,

> I, personally, think that's wrong and
>it should be reporting the error on LIBRTL

A reasonable opinion, and one that I tend to agree with, but unfortunately for us, the person who implemented the code didn't.

The error is, technically correct. We failed to activate "DIR_WATCH_EXEC" and the reason was "PRIVINSTAL":

"o An attempt was made to run a privileged image with uninstalled shareable images."

Obviously it would be more informative to name the image which caused the problem rather than the victim, but that's just semantics.

A little history... there are (were?) two camps of opinion in issuing error messages. I call them the "paranoids" and the "pragmatists".

The philosophy of the paranoids was to LIMIT the amount of information revealed by an error message in order to hinder hackers. Hence "NOPRIV" and "EXQUOTA" -"Don't actually TELL them which privilege or quota, then they know what to shoot for. Any legitimate user should already know"

The pragmatists say that's a crock, and complain about the hours of wasted time by legitimate users trying to figure out WHICH quota or privilege was missing.

For many years the paranoids held on, but around V6, the pragmatists finally won through, and a whole set of new, more specific messages were created NOPRIV_CMKRNL, EXQUOTA_BYTLM etc... All new code is supposed to use the more informative status codes.

However, old code paths still use the old, paranoid codes. As code is revised, some MAY be updated, but the stuff that's deep down in the kernel will probably remain (especially if everyone stops paying support contracts and starves OpenVMS engineering of funding).

To debug this kind of error, try IMAGETREE.COM from the freeware, it displays the shareable image dependence tree for a given image. It's then a matter of checking each image in the path.

Trusted logical names are EXEC mode in the EXEC mode path of LNM$FILE_DEV

$ SHOW LOG/TABLE=*DIRECTORY LNM$FILE*/FULL

So, you can set up a process specific redirection.
A crucible of informative mistakes
John Gillings
Honored Contributor

Re: Wrong image name identified in IMGNAME error message

Richard,

Note that you're not supposed to call user mode routines from inner modes. You might be able to, BUT beware that you may be opening security holes or creating system crashers. Once you're inside a protected image, you OWN the system. Security and system integrity is entirely in your hands. For a start, I'd want to see some far more extensive validation of arguments before deploying your code on one of my systems.

Please check your assumptions carefully. I've tried that approach before. It's very expensive as your lock will be triggered by many more events than just file creations. My conclusion was it was actually cheaper, and certainly safer to just poll the directory. It also tells you when the file was created, not when it gets closed (which is presumably far more interesting and useful). I'm also certain that you can do all that without resorting to inner mode.

See:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=940030
A crucible of informative mistakes
Richard J Maher
Trusted Contributor

Re: Wrong image name identified in IMGNAME error message

Hi John,

Thanks for the reply. (It's not that I stopped paying a support contract, I just never had one :-) I do have a SDK license and a DSPP membership and I'm a nice bloke.

I think I follow your argument, but that should leave us with either a message with *no* image name or a message with the *correct* image name. We currently have neither of those options.

Anyway, who cares? I honestly couldn't give two proverbials as to what image name shows up, and it was really only another chance to extract more information from you and to show off some code I had lying around but please answer me this: -

Why do you discuss "trusted" logical names at EXEC mode when the image activator is clearly *and evidently* happy to persue SUPERVISOR mode logical names for LIBRTL?

TIER3> @dir_watch
%COPY-S-COPIED, TIER3_SYSMAN:[MAHER_R.TRASH]DIR_WATCH_EXEC.EXE;2 copied to SYS$COMMON:[SYSLIB]DIR_WATCH_EXEC.EXE;4 (20 blocks)
%COPY-S-COPIED, TIER3_SYSMAN:[MAHER_R.TRASH]DIR_WATCH_USER.EXE;2 copied to SYS$COMMON:[SYSLIB]DIR_WATCH_USER.EXE;4 (7 blocks)
TIER3> define librtl TIER3_SYSMAN:[MAHER_R.UWSS]librtl
TIER3> run test_dir
%DCL-W-ACTIMAGE, error activating image DIR_WATCH_EXEC
-CLI-E-IMGNAME, image file TIER3$DKA200:[SYS0.SYSCOMMON.][SYSLIB]DIR_WATCH_EXEC.EXE
-SYSTEM-F-PRIVINSTALL, shareable images must be installed to run privileged image
TIER3> sh log librtl/full
"LIBRTL" [super] = "TIER3_SYSMAN:[MAHER_R.UWSS]LIBRTL" (LNM$PROCESS_TABLE)

Not trying to be funny John, but do you see the bit that says *[SUPER]*? Am I misunderstanding something?

If only developers could look up "Them" rules then we could save us all a lot of time! Where are they?

Cheers Richard

PS. Do you stop looking at threads once the little rabbit has been assigned? Should I hold off assigning points until a thread has been exhausted?
Richard J Maher
Trusted Contributor

Re: Wrong image name identified in IMGNAME error message

Hi,

[ For a start, I'd want to see some far more extensive validation of arguments before deploying your code on one of my systems.]

Oh really? Which ones? (Specifically) I'm going out the door right now but I think "them" rules of coutesy and far play require some substantiation and a right-of-reply on my behalf. If it needs fixing then please let me know.

I'll address your other points when I get back, but can we try to leave the "there be dragons" arguments outside and try to concentrate on the science? If we can move forward on the premise that everyone has lay prostrate in from of the EXEC alter and UWSSs are an essential part of VMS functionality *and* that it is in *everyone's* best interest that they get written properly, then that would be just peachy!

Cheers Richard.
Phil.Howell
Honored Contributor

Re: Wrong image name identified in IMGNAME error message

I do get different results from you, :)
but not in the way that I expected. :(

I would have expected test_dir to have been installed with privilege to achieve your results.

Was it installed? what privs?

If you answer you own questions in this forum, can you award yourself points?

Phil

John Gillings
Honored Contributor

Re: Wrong image name identified in IMGNAME error message

Richard,

>Oh really? Which ones? (Specifically)

See the code in your MACRO defining the service:

cmpb (ap),#narg
bgeq endmacro
movzwl #ss$_insfarg,r0
ret

This checks the argument count, but doesn't check that AP points anywhere first. A null argument list will result in an ACCVIO. In kernel mode that takes out the whole system. Even if the argument COUNT is valid, there's no attempt to make sure the entire (apparent) argument list is accessible. The AP could point to the last longword in mapped memory. Referencing 4(AP) or beyond could ACCVIO. You're already in kernel or exec mode at this time, so NOTHING the user gives you can be trusted.

>Do you stop looking at threads once
>the little rabbit has been assigned?

ITRC is entirely voluntary. It's pretty much at the bottom of my priorities. I will contribute when I have time, and believe it's well spent. I don't come here to "spar" or score points (figurative or literal). If I get the impression my opinion or advice is not wanted, or will be ignored, I don't waste anyone's time by posting it.

In this case my opinion is there is no need to be doing any of this in kernel or exec mode. I recommend you step back, consider what you're really trying to achieve and look at safer means to achieve it.
A crucible of informative mistakes