Discussion:
Starting from en entry point in a shareable image from DCL.
(too old to reply)
Jan-Erik Soderholm
2014-05-14 09:09:21 UTC
Permalink
Hi.

First, don't ask *why* things are as they are, this is a
30+ year old system and I'm sure they had some good reason
to build it as it is when run on some VAX 11/xxx system...

Envir:
AS DS20e
OpenVMS 8.2
Language Cobol

We have some applications that are linked as a shareable image:

$ LINK/EXE=MK_ARK:MK.EXE/SHARE -
MK_ARK:aaa.OBJ,-
MK_ARK:bbb.OBJ,-
MK_ARK:ccc.OBJ,-
SYS$INPUT:/OPTION
MKSHARE/SHARE
SYMBOL_VECTOR=(aaa=PROCEDURE,-
bbb=PROCEDURE,-
ccc=PROCEDURE)

(MKSHARE is another shareable image, but that is not an issue.)

This apps are then run from our menu system that does know
how to start from a specific entry point/vector. You configure
the menu item with the name of the image (MK.EXE) and the name
of the entry point/vector (like aaa, bbb or ccc above).

The problem is that on our test system we don't have
access to that menu system. I have not found any easy
way to RUN from the DCL prompt from one of these
entry points/vectors in the shearable image.

What I'm doing at the moment when there is a need for
some testing of a specific application (like aaa, bbb
or ccc above), is to relink it as a stand-alone EXE.

But of course, that will not be *exactly* the same test
environment as the one running in prod.

So, what are the options to call/run from one of these
entry points/vectors in the shareable EXE ? Do we have
to build a spearate EXE that only does a CALL to one
of these apps (aaa, bbb or ccc) ?

Thanks,
Jan-Erik.
hb
2014-05-14 11:43:11 UTC
Permalink
Post by Jan-Erik Soderholm
So, what are the options to call/run from one of these
entry points/vectors in the shareable EXE ? Do we have
to build a spearate EXE that only does a CALL to one
of these apps (aaa, bbb or ccc) ?
Writing a main image, which links against the shareable one and which
calls the "apps" is probably the right and best solution.

The other options are hacks or require changes to the shareable image.
You can patch/abs the image and swap the entry point (you need to know
where that is in the image and what to put there - the latter should be
in the linker map). You can add your main to the shareable image and do
the same calls as if in the separate image.
Joukj
2014-05-14 11:45:34 UTC
Permalink
Post by Jan-Erik Soderholm
Hi.
First, don't ask *why* things are as they are, this is a
30+ year old system and I'm sure they had some good reason
to build it as it is when run on some VAX 11/xxx system...
AS DS20e
OpenVMS 8.2
Language Cobol
$ LINK/EXE=MK_ARK:MK.EXE/SHARE -
MK_ARK:aaa.OBJ,-
MK_ARK:bbb.OBJ,-
MK_ARK:ccc.OBJ,-
SYS$INPUT:/OPTION
MKSHARE/SHARE
SYMBOL_VECTOR=(aaa=PROCEDURE,-
bbb=PROCEDURE,-
ccc=PROCEDURE)
(MKSHARE is another shareable image, but that is not an issue.)
This apps are then run from our menu system that does know
how to start from a specific entry point/vector. You configure
the menu item with the name of the image (MK.EXE) and the name
of the entry point/vector (like aaa, bbb or ccc above).
The problem is that on our test system we don't have
access to that menu system. I have not found any easy
way to RUN from the DCL prompt from one of these
entry points/vectors in the shearable image.
What I'm doing at the moment when there is a need for
some testing of a specific application (like aaa, bbb
or ccc above), is to relink it as a stand-alone EXE.
But of course, that will not be *exactly* the same test
environment as the one running in prod.
So, what are the options to call/run from one of these
entry points/vectors in the shareable EXE ? Do we have
to build a spearate EXE that only does a CALL to one
of these apps (aaa, bbb or ccc) ?
Thanks,
Jan-Erik.
You need create a small program that
1) gets the location in the shareable image using
LIB$FIND_IMAGE_SYMBOL
2) Call the procedure using LIB$CALLG


Regards
Jouk
V***@SendSpamHere.ORG
2014-05-14 12:17:56 UTC
Permalink
Post by Jan-Erik Soderholm
Hi.
First, don't ask *why* things are as they are, this is a
30+ year old system and I'm sure they had some good reason
to build it as it is when run on some VAX 11/xxx system...
AS DS20e
OpenVMS 8.2
Language Cobol
$ LINK/EXE=MK_ARK:MK.EXE/SHARE -
MK_ARK:aaa.OBJ,-
MK_ARK:bbb.OBJ,-
MK_ARK:ccc.OBJ,-
SYS$INPUT:/OPTION
MKSHARE/SHARE
SYMBOL_VECTOR=(aaa=PROCEDURE,-
bbb=PROCEDURE,-
ccc=PROCEDURE)
(MKSHARE is another shareable image, but that is not an issue.)
This apps are then run from our menu system that does know
how to start from a specific entry point/vector. You configure
the menu item with the name of the image (MK.EXE) and the name
of the entry point/vector (like aaa, bbb or ccc above).
The problem is that on our test system we don't have
access to that menu system. I have not found any easy
way to RUN from the DCL prompt from one of these
entry points/vectors in the shearable image.
What I'm doing at the moment when there is a need for
some testing of a specific application (like aaa, bbb
or ccc above), is to relink it as a stand-alone EXE.
But of course, that will not be *exactly* the same test
environment as the one running in prod.
So, what are the options to call/run from one of these
entry points/vectors in the shareable EXE ? Do we have
to build a spearate EXE that only does a CALL to one
of these apps (aaa, bbb or ccc) ?
Thanks,
Jan-Erik.
LIB$FIND_IMAGE_SYMBOL
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Stephen Hoffman
2014-05-14 12:25:20 UTC
Permalink
So, what are the options to call/run from one of these entry
points/vectors in the shareable EXE ? Do we have to build a spearate
EXE that only does a CALL to one of these apps (aaa, bbb or ccc) ?
Either port the menu environment to the test servers (which would
better replicate the production environment), or add shims into the
code in the shareable to allow easier testing, or use logical name
image redirection or lib$find_image_symbol or the C dynamic loader
routines or a static link against the shareable image to find and
activate the target code from within a testing-related stub main image.

Possibly a stub main image that uses C argument processing or CLI
callbacks to provide the "wrapper" that you're seemingly looking for.

DCL does not have symbol-level constructs for executables; RUN and the
Foreign Commands (is that a VMS nerd band?) are largely what you have
available in DCL for image image invocation.
--
Pure Personal Opinion | HoffmanLabs LLC
Jan-Erik Soderholm
2014-05-14 12:56:22 UTC
Permalink
So, what are the options to call/run from one of these entry
points/vectors in the shareable EXE ? Do we have to build a spearate EXE
that only does a CALL to one of these apps (aaa, bbb or ccc) ?
Either port the menu environment to the test servers (which would better
replicate the production environment), or add shims into the code in the
shareable to allow easier testing, or use logical name image redirection or
lib$find_image_symbol or the C dynamic loader routines or a static link
against the shareable image to find and activate the target code from
within a testing-related stub main image.
Possibly a stub main image that uses C argument processing or CLI callbacks
to provide the "wrapper" that you're seemingly looking for.
DCL does not have symbol-level constructs for executables; RUN and the
Foreign Commands (is that a VMS nerd band?) are largely what you have
available in DCL for image image invocation.
OK, thanks!

We can't run (or "port") the menu handler to the test box, it is
a license issue, and the issuer is long gone...

OK, a small Cobol routine that just makes a CALL to the
entry vectors will be tried. B.t.w, isn't the find_image_symbol
stuff done at link time, if the shareable is included/referenced
in the link option file?

I do not think we use the lib$find_image_symbol call in our
apps that calls other entries in the same shareable...

Jan-Erik.
Stephen Hoffman
2014-05-14 13:10:06 UTC
Permalink
We can't run (or "port") the menu handler to the test box, it is a
license issue, and the issuer is long gone...
There can be paths to resolve that, so long as there's some entity
around that acknowledges ownership of the rubble of the issuer.
OK, a small Cobol routine that just makes a CALL to the entry vectors
will be tried.
That's a stub. Static linked.
B.t.w, isn't the find_image_symbol stuff done at link time, if the
shareable is included/referenced in the link option file?
No. lib$find_image_symbol finds and loads and image-activates the
specified shareable image and the specified symbol dynamically; at
run-time.

Contrast this with the static link-time approach you're using with that
COBOL stub main executable image.
I do not think we use the lib$find_image_symbol call in our apps that
calls other entries in the same shareable...
I would not really expect that, either. COBOL 2002 added pointer
support and related, but VMS lacks a compiler with support for that
standard.
--
Pure Personal Opinion | HoffmanLabs LLC
John Reagan
2014-05-20 18:01:59 UTC
Permalink
Post by Stephen Hoffman
COBOL 2002 added pointer
support and related, but VMS lacks a compiler with support for that
standard.
As extensions, OpenVMS COBOL has "USAGE IS POINTER" and "USAGE IS POINTER-64". The pointer support doesn't let you do much other than carry them around from one place to another.
Bill Gunshannon
2014-05-20 18:18:30 UTC
Permalink
Post by John Reagan
Post by Stephen Hoffman
COBOL 2002 added pointer
support and related, but VMS lacks a compiler with support for that
standard.
As extensions, OpenVMS COBOL has "USAGE IS POINTER" and "USAGE IS
POINTER-64". The pointer support doesn't let you do much other
than carry them around from one place to another.
Having played with this feature quite a bit in GNU COBOL I feel safe
saying the primary reason it was added was to make it easier to inteface
with other languages, like C, that have this thing about passing things
around using pointers. I wrote a COBOL Library for accessing Postgres
(in COBOL) in order to better hide the ugliness needed to do it.

bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
hb
2014-05-14 13:15:22 UTC
Permalink
Post by Jan-Erik Soderholm
OK, a small Cobol routine that just makes a CALL to the
entry vectors will be tried. B.t.w, isn't the find_image_symbol
stuff done at link time, if the shareable is included/referenced
in the link option file?
No, the linker resolves (global) symbols, from objects and shareable
images. For that, the linker opens and reads the object and image files,
they are not activated. The linker only needs to resolve symbols for the
image it links, that's just one level of dependencies.
Lib$find_image_symbol activates the shareable image with the given
symbol. Activting an image also means to activate all shareable images
that the image depends on.
Jan-Erik Soderholm
2014-05-14 13:48:20 UTC
Permalink
Post by hb
Post by Jan-Erik Soderholm
OK, a small Cobol routine that just makes a CALL to the
entry vectors will be tried. B.t.w, isn't the find_image_symbol
stuff done at link time, if the shareable is included/referenced
in the link option file?
No, the linker resolves (global) symbols, from objects and shareable
images. For that, the linker opens and reads the object and image files,
they are not activated. The linker only needs to resolve symbols for the
image it links, that's just one level of dependencies.
Lib$find_image_symbol activates the shareable image with the given symbol.
Activting an image also means to activate all shareable images that the
image depends on.
What I ment was that the linker "finds" the routines in the
shareable at link time, just as Lib$find_image_symbol finds
it at run time.

Anyway, I get it. Currenly doing a small stubb to call our app...

Jan-Erik.
JF Mezei
2014-05-15 07:41:16 UTC
Permalink
Post by Jan-Erik Soderholm
What I ment was that the linker "finds" the routines in the
shareable at link time, just as Lib$find_image_symbol finds
it at run time.
static linker means that you have to preserve your entry point
locations. so when you update the shareable image, you need to be
careful (hence use of transfer vectors at top of image).

with lib$find_image_symbol, you have more freedom to update shareable
image and not worry about location of entry points.


lib$find_image_symbol also allows you to choose a shareable image at run
time. (choose approriate shareable image corresponding to device entered
by user).
hb
2014-05-15 09:26:09 UTC
Permalink
On 05/15/2014 09:41 AM, JF Mezei wrote:

As usual, there are pros and cons.
Post by JF Mezei
static linker means that you have to preserve your entry point
locations. so when you update the shareable image, you need to be
careful (hence use of transfer vectors at top of image).
OP said "test system". I don't know the details, but if the symbol
vector entries - OP said Alpha - changed, it should be possible to
relink the main test image.
Post by JF Mezei
with lib$find_image_symbol, you have more freedom to update shareable
image and not worry about location of entry points.
True and there is more freedom with GSMATCH: lib$find_image_symbol can't
and doesn't check it.
Post by JF Mezei
lib$find_image_symbol also allows you to choose a shareable image at run
time. (choose approriate shareable image corresponding to device entered
by user).
Same with statically linked images: at run time define a logical
pointing to whatever shareable image you want to be activated.
JF Mezei
2014-05-15 17:27:10 UTC
Permalink
Post by hb
Same with statically linked images: at run time define a logical
pointing to whatever shareable image you want to be activated.
Nop. With static linking, the resolution of the logical is made at image
activation time, so the application cannot change it on the fly and open
a different shareable image.

With lib$find_image_symbol, you can because the shareable image is not
resolved at image activation before your program's logic can decide
which shareable image to open.

(context: application decides whcih shareable image to use based on
input from customer).
Jan-Erik Soderholm
2014-05-15 18:01:01 UTC
Permalink
Post by JF Mezei
Post by hb
Same with statically linked images: at run time define a logical
pointing to whatever shareable image you want to be activated.
Nop. With static linking, the resolution of the logical is made at image
activation time, so the application cannot change it on the fly and open
a different shareable image.
What is what I guess he ment (and also as I read it), you define the
logical, *then* you run our main image, of course.
Post by JF Mezei
With lib$find_image_symbol, you can because the shareable image is not
resolved at image activation before your program's logic can decide
which shareable image to open.
(context: application decides whcih shareable image to use based on
input from customer).
Paul Sture
2014-05-15 18:17:59 UTC
Permalink
Post by Jan-Erik Soderholm
Post by JF Mezei
Post by hb
Same with statically linked images: at run time define a logical
pointing to whatever shareable image you want to be activated.
Nop. With static linking, the resolution of the logical is made at image
activation time, so the application cannot change it on the fly and open
a different shareable image.
What is what I guess he ment (and also as I read it), you define the
logical, *then* you run our main image, of course.
That's how I understood it too. We used to use group logicals here, so
could run different versions on the same machine (e.g. test and development).
--
Paul Sture

The final step of #heartbleed recovery is to call your mother, and advise
her to change her maiden name -- @gojomo
hb
2014-05-15 18:19:31 UTC
Permalink
Post by JF Mezei
Post by hb
Same with statically linked images: at run time define a logical
Post by hb
pointing to whatever shareable image you want to be activated.
Nop. With static linking, the resolution of the logical is made at image
activation time, so the application cannot change it on the fly and open
a different shareable image.
With lib$find_image_symbol, you can because the shareable image is not
resolved at image activation before your program's logic can decide
which shareable image to open.
Yes, you are right, that's not the same. With lib$find_image_symbol you
are more flexible.
V***@SendSpamHere.ORG
2014-05-15 21:58:10 UTC
Permalink
Post by hb
Post by JF Mezei
Post by hb
Same with statically linked images: at run time define a logical
Post by hb
pointing to whatever shareable image you want to be activated.
Nop. With static linking, the resolution of the logical is made at image
activation time, so the application cannot change it on the fly and open
a different shareable image.
With lib$find_image_symbol, you can because the shareable image is not
resolved at image activation before your program's logic can decide
which shareable image to open.
Yes, you are right, that's not the same. With lib$find_image_symbol you
are more flexible.
And, with $IMGACT/$IMGFIX you have even more flexibilty. ;)
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
David Froble
2014-05-15 23:29:54 UTC
Permalink
Post by V***@SendSpamHere.ORG
Post by hb
Post by JF Mezei
Post by hb
Same with statically linked images: at run time define a logical
Post by hb
pointing to whatever shareable image you want to be activated.
Nop. With static linking, the resolution of the logical is made at image
activation time, so the application cannot change it on the fly and open
a different shareable image.
With lib$find_image_symbol, you can because the shareable image is not
resolved at image activation before your program's logic can decide
which shareable image to open.
Yes, you are right, that's not the same. With lib$find_image_symbol you
are more flexible.
And, with $IMGACT/$IMGFIX you have even more flexibilty. ;)
Ya know, I've never used this capability, never had the need. Also am
not familiar with it.

But, it occurs to me, in certain circumstances, it could be a security
issue.

As an example, you have a RTL with some routines that are called only
from within the RTL, and say one of the routines is set up to perform
some privileged operation. With this capability, someone could find the
entry point and invoke the routine doing the privileged stuff.

Or am I missing something rather basic?
JF Mezei
2014-05-16 00:50:41 UTC
Permalink
Post by David Froble
Post by V***@SendSpamHere.ORG
And, with $IMGACT/$IMGFIX you have even more flexibilty. ;)
Ya know, I've never used this capability, never had the need. Also am
not familiar with it.
In a Lord of the Rings analogy:

You live on the surface (user mode)
Mr VAXman lives in Middle Earth (kernel mode)

:-)
V***@SendSpamHere.ORG
2014-05-16 13:11:06 UTC
Permalink
Post by JF Mezei
Post by David Froble
Post by V***@SendSpamHere.ORG
And, with $IMGACT/$IMGFIX you have even more flexibilty. ;)
Ya know, I've never used this capability, never had the need. Also am
not familiar with it.
You live on the surface (user mode)
Mr VAXman lives in Middle Earth (kernel mode)
Save that both $IMGACT and $IMGFIX can be used, quite successfully too, in
user mode.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
V***@SendSpamHere.ORG
2014-05-16 13:09:01 UTC
Permalink
Post by David Froble
Post by V***@SendSpamHere.ORG
Post by hb
Post by JF Mezei
Post by hb
Same with statically linked images: at run time define a logical
Post by hb
pointing to whatever shareable image you want to be activated.
Nop. With static linking, the resolution of the logical is made at image
activation time, so the application cannot change it on the fly and open
a different shareable image.
With lib$find_image_symbol, you can because the shareable image is not
resolved at image activation before your program's logic can decide
which shareable image to open.
Yes, you are right, that's not the same. With lib$find_image_symbol you
are more flexible.
And, with $IMGACT/$IMGFIX you have even more flexibilty. ;)
Ya know, I've never used this capability, never had the need. Also am
not familiar with it.
But, it occurs to me, in certain circumstances, it could be a security
issue.
As an example, you have a RTL with some routines that are called only
from within the RTL, and say one of the routines is set up to perform
some privileged operation. With this capability, someone could find the
entry point and invoke the routine doing the privileged stuff.
Or am I missing something rather basic?
You can't get there from here. No more insecure than invoking a routine
that was mapped using LIB$FIND_IMAGE_SYMBOL. Unless a process possesses
the privileges to perform a privileged function, mapping an image into a
process that performs a privileged function[*] will fail with SS$_NOPRIV
when that privileged function is exercised.

[*] Notwithstanding images with a privilege vector; however, VMS enforces
that these be installed, an action which required privileges to perform.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
David Froble
2014-05-16 16:25:32 UTC
Permalink
Post by V***@SendSpamHere.ORG
Post by David Froble
Post by V***@SendSpamHere.ORG
Post by hb
Post by JF Mezei
Post by hb
Same with statically linked images: at run time define a logical
Post by hb
pointing to whatever shareable image you want to be activated.
Nop. With static linking, the resolution of the logical is made at image
activation time, so the application cannot change it on the fly and open
a different shareable image.
With lib$find_image_symbol, you can because the shareable image is not
resolved at image activation before your program's logic can decide
which shareable image to open.
Yes, you are right, that's not the same. With lib$find_image_symbol you
are more flexible.
And, with $IMGACT/$IMGFIX you have even more flexibilty. ;)
Ya know, I've never used this capability, never had the need. Also am
not familiar with it.
But, it occurs to me, in certain circumstances, it could be a security
issue.
As an example, you have a RTL with some routines that are called only
from within the RTL, and say one of the routines is set up to perform
some privileged operation. With this capability, someone could find the
entry point and invoke the routine doing the privileged stuff.
Or am I missing something rather basic?
You can't get there from here. No more insecure than invoking a routine
that was mapped using LIB$FIND_IMAGE_SYMBOL. Unless a process possesses
the privileges to perform a privileged function, mapping an image into a
process that performs a privileged function[*] will fail with SS$_NOPRIV
when that privileged function is exercised.
[*] Notwithstanding images with a privilege vector; however, VMS enforces
that these be installed, an action which required privileges to perform.
I wasn't too specific. It was LIB$FIND_IMAGE_SYMBOL that I was
referring to.

If the RTL is installed with privs, and the routine does a CMEXEC or
CMKRNL to perform some operation, then if the routine is invoked from
something that finds the symbol, then would that program without prive
still be able to perform the CM????

I have that specific case, in a RTL that needed SYSLCK but the users
would not have that priv.

Maybe I should get off my lazy ass and RTFM ....
V***@SendSpamHere.ORG
2014-05-16 19:25:12 UTC
Permalink
Post by David Froble
Post by V***@SendSpamHere.ORG
Post by David Froble
Post by V***@SendSpamHere.ORG
Post by hb
Post by JF Mezei
Post by hb
Same with statically linked images: at run time define a logical
Post by hb
pointing to whatever shareable image you want to be activated.
Nop. With static linking, the resolution of the logical is made at image
activation time, so the application cannot change it on the fly and open
a different shareable image.
With lib$find_image_symbol, you can because the shareable image is not
resolved at image activation before your program's logic can decide
which shareable image to open.
Yes, you are right, that's not the same. With lib$find_image_symbol you
are more flexible.
And, with $IMGACT/$IMGFIX you have even more flexibilty. ;)
Ya know, I've never used this capability, never had the need. Also am
not familiar with it.
But, it occurs to me, in certain circumstances, it could be a security
issue.
As an example, you have a RTL with some routines that are called only
from within the RTL, and say one of the routines is set up to perform
some privileged operation. With this capability, someone could find the
entry point and invoke the routine doing the privileged stuff.
Or am I missing something rather basic?
You can't get there from here. No more insecure than invoking a routine
that was mapped using LIB$FIND_IMAGE_SYMBOL. Unless a process possesses
the privileges to perform a privileged function, mapping an image into a
process that performs a privileged function[*] will fail with SS$_NOPRIV
when that privileged function is exercised.
[*] Notwithstanding images with a privilege vector; however, VMS enforces
that these be installed, an action which required privileges to perform.
I wasn't too specific. It was LIB$FIND_IMAGE_SYMBOL that I was
referring to.
If the RTL is installed with privs, and the routine does a CMEXEC or
CMKRNL to perform some operation, then if the routine is invoked from
something that finds the symbol, then would that program without prive
still be able to perform the CM????
When you can INSTALL an RTL with privileges, you let me know.
Post by David Froble
I have that specific case, in a RTL that needed SYSLCK but the users
would not have that priv.
IF an RTL requires SYSLCK privilege to, for some controlled reason within
that RTL, perform its task, you create a privileged shareable image (user
written system services) and install it as such. The image invoking it,
regardless of the user's lack of a necessary specific privilege, can then
perform its task.
Post by David Froble
Maybe I should get off my lazy ass and RTFM ....
...and then, RRTFM.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
David Froble
2014-05-17 01:48:29 UTC
Permalink
Post by V***@SendSpamHere.ORG
Post by David Froble
If the RTL is installed with privs, and the routine does a CMEXEC or
CMKRNL to perform some operation, then if the routine is invoked from
something that finds the symbol, then would that program without prive
still be able to perform the CM????
When you can INSTALL an RTL with privileges, you let me know.
Yeah, it just shows how pervasive the senility has progressed ..

DISK$VMS072:<SYS0.SYSLIB>.EXE
DASRTL;13 Open Hdr Shar Prot Lnkbl

This is how the RTL is installed.

Now, the following was written in 1984, and it's been over 10 years
since I did any MACRO-32. Take pity, my head hurts ..

;+
; The following routines will run in EXEC mode
;-

XVECTOR ROUTINE=DAS_VINIT,MODE=EXEC,UNIVERSAL=NO

 .PAGE
.SUBTITLE Privileged library vector

.PSECT PLV,CON,LCL,NOEXE,PIC,RD,REL,SHR,NOWRT,VEC,PAGE

.LONG PLV$C_TYP_CMOD ; This is a change mode vector
.LONG SYS$K_VERSION ; System version
.LONG 0 ; No kernel mode dispatcher
.LONG DSPEXEC - . ; Offset to EXEC mode dispatcher
.LONG 0 ; No rundown service
.LONG 0 ; Reserved
.LONG 0 ; No RMS dispatcher
.LONG 0 ; PIC image

 .PAGE
.SUBTITLE Executive mode dispatcher

;++
;
; Abstract:
;
; This is the executive mode dispatcher invoked by the VMS
; executive mode change mode dispatcher when a system service code
; (index) is not recognized by it.
;
; Input parameters:
;
; (SP) = Return address if index is not ours
; R0 = Change modex index
; AP = Argument pointer
; FP = Call frame for exit
;
;--

.GLOBAL DSPEXEC

DSPEXEC:

MNEGL R0,R0 ; Make index positive
BGTR 200$ ; Continue if GT zero
100$: RSB ; Return, not this dispatcher
200$: CASEL R0,#1,#-DAS_MAXEXEC ; Dispatch on index

000$: .WORD DAS_VINIT + 2 - 000$

RSB
Post by V***@SendSpamHere.ORG
Post by David Froble
I have that specific case, in a RTL that needed SYSLCK but the users
would not have that priv.
IF an RTL requires SYSLCK privilege to, for some controlled reason within
that RTL, perform its task, you create a privileged shareable image (user
written system services) and install it as such. The image invoking it,
regardless of the user's lack of a necessary specific privilege, can then
perform its task.
Post by David Froble
Maybe I should get off my lazy ass and RTFM ....
...and then, RRTFM.
Yeah, but then my head would hurt worse.

:-)

As I wrote, I've never used LIB$FIND_IMAGE_SYMBOL, so I'm pretty clueless.

What I've wondered is whether that EXEC mode routine can be used by
finding the symbol in the RTL. After looking at things, I'm thinking
not, but as I wrote, it's been a long time, and if you don't do MACRO
constantly, you don't do it well, or at all.
V***@SendSpamHere.ORG
2014-05-17 10:23:16 UTC
Permalink
Post by David Froble
Post by V***@SendSpamHere.ORG
Post by David Froble
If the RTL is installed with privs, and the routine does a CMEXEC or
CMKRNL to perform some operation, then if the routine is invoked from
something that finds the symbol, then would that program without prive
still be able to perform the CM????
When you can INSTALL an RTL with privileges, you let me know.
Yeah, it just shows how pervasive the senility has progressed ..
The mind is the second thing to go, so I've been told.
Post by David Froble
DISK$VMS072:<SYS0.SYSLIB>.EXE
DASRTL;13 Open Hdr Shar Prot Lnkbl
This is how the RTL is installed.
Now, the following was written in 1984, and it's been over 10 years
since I did any MACRO-32. Take pity, my head hurts ..
;+
; The following routines will run in EXEC mode
;-
XVECTOR ROUTINE=DAS_VINIT,MODE=EXEC,UNIVERSAL=NO
 .PAGE
.SUBTITLE Privileged library vector
.PSECT PLV,CON,LCL,NOEXE,PIC,RD,REL,SHR,NOWRT,VEC,PAGE
.LONG PLV$C_TYP_CMOD ; This is a change mode vector
.LONG SYS$K_VERSION ; System version
.LONG 0 ; No kernel mode dispatcher
.LONG DSPEXEC - . ; Offset to EXEC mode dispatcher
.LONG 0 ; No rundown service
.LONG 0 ; Reserved
.LONG 0 ; No RMS dispatcher
.LONG 0 ; PIC image
 .PAGE
.SUBTITLE Executive mode dispatcher
;++
;
;
; This is the executive mode dispatcher invoked by the VMS
; executive mode change mode dispatcher when a system service code
; (index) is not recognized by it.
;
;
; (SP) = Return address if index is not ours
; R0 = Change modex index
; AP = Argument pointer
; FP = Call frame for exit
;
;--
.GLOBAL DSPEXEC
MNEGL R0,R0 ; Make index positive
BGTR 200$ ; Continue if GT zero
100$: RSB ; Return, not this dispatcher
200$: CASEL R0,#1,#-DAS_MAXEXEC ; Dispatch on index
000$: .WORD DAS_VINIT + 2 - 000$
RSB
Post by V***@SendSpamHere.ORG
Post by David Froble
I have that specific case, in a RTL that needed SYSLCK but the users
would not have that priv.
IF an RTL requires SYSLCK privilege to, for some controlled reason within
that RTL, perform its task, you create a privileged shareable image (user
written system services) and install it as such. The image invoking it,
regardless of the user's lack of a necessary specific privilege, can then
perform its task.
Post by David Froble
Maybe I should get off my lazy ass and RTFM ....
...and then, RRTFM.
Yeah, but then my head would hurt worse.
:-)
As I wrote, I've never used LIB$FIND_IMAGE_SYMBOL, so I'm pretty clueless.
What I've wondered is whether that EXEC mode routine can be used by
finding the symbol in the RTL. After looking at things, I'm thinking
not, but as I wrote, it's been a long time, and if you don't do MACRO
constantly, you don't do it well, or at all.
Well, this is VMS internals, not necessarily Macro. These things can also
be done in Bliss, some HLLs or C since the advent of OpenVMS Alpha.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Paul Sture
2014-05-17 15:40:59 UTC
Permalink
Post by V***@SendSpamHere.ORG
Post by David Froble
Yeah, it just shows how pervasive the senility has progressed ..
The mind is the second thing to go, so I've been told.
Oh, I thought it was the third thing.

After the hair and the teeth, of course.
--
Paul Sture

The final step of #heartbleed recovery is to call your mother, and advise
her to change her maiden name -- @gojomo
V***@SendSpamHere.ORG
2014-05-17 17:22:05 UTC
Permalink
Post by Paul Sture
Post by V***@SendSpamHere.ORG
Post by David Froble
Yeah, it just shows how pervasive the senility has progressed ..
The mind is the second thing to go, so I've been told.
Oh, I thought it was the third thing.
After the hair and the teeth, of course.
In that case, I still must have my mind as I have both teeth and plenty of
hair! Loading Image...

So, I should be wary of toothless baldies?
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
JF Mezei
2014-05-17 20:48:36 UTC
Permalink
In that case, I still must have my mind as I have both teeth ...
If the mind is associated with how many teeth you have left, bragging
about still having 2 teeth says a lot about how much of a mind you
started off with :-) No wonder you can't rise above kernel mode :-)
V***@SendSpamHere.ORG
2014-05-18 13:15:34 UTC
Permalink
Post by JF Mezei
In that case, I still must have my mind as I have both teeth ...
If the mind is associated with how many teeth you have left, bragging
about still having 2 teeth says a lot about how much of a mind you
started off with :-) No wonder you can't rise above kernel mode :-)
Au contraire, I still possess all 32 bit(e)s.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
David Froble
2014-05-17 19:26:50 UTC
Permalink
Post by V***@SendSpamHere.ORG
The mind is the second thing to go, so I've been told.
I think you may be right ...

#1, check

#2, check

Now I got to wonder what #3 will be.
m***@gmail.com
2014-05-15 23:19:09 UTC
Permalink
Here's one way to do it

status = lib$find_image_symbol ("MENU_APP:MK", <entry_pt_name>, &ret_address)

Just define logical MENU_APP to point to whatever directory you want to use. It cannot be a directory specification. The documentation for lib$find_image_symbol lets you specify a related filename as per RMS, but why bother if your logical points to where you want to be?

When you have the function address you call that, passing the appropriate parameters for that routine.

Where I work we use this kind of thing all the time. It saves having to link routines against each other; the only thing we do link against is our routine that does the LIB$FIND_IMAGE_SYMBOL. We tell it the name of the entry point and it looks up a table to find the executable image that contains that entry point. We also use it for the recent SSL upgrade (to v1.4?) where we call SSL routines from our application, our VMS version being 8.3 and using v1.3 itself.
hb
2014-05-16 08:29:53 UTC
Permalink
Post by m***@gmail.com
Just define logical MENU_APP to point to whatever directory you want
to use. It cannot be a directory specification. The documentation for
lib$find_image_symbol lets you specify a related filename as per RMS,
but why bother if your logical points to where you want to be?

It depends on when you define the logical. If you define it before you
run your main, then there is no benefit using lib$find_image_symbol (for
an image with transfer/symbol vectors). The only difference is in using
more cpu time and resources. If you define the logical from your main,
depending on user input, then you have an additional level of
flexibility (which you have to pay for). - I misunderstood the "at run
time" as specifying the shareable image before activating the main image.

You pay for reading the global symbol table from the image file. The
image activator doesn't need/use these symbols. As you probably know,
after linking your main image with a shareable one, you can relink your
shareable image without the symbol table (for whatever reason, for
example to make the image file smaller). Image activation still works,
but lib$find_image_symbol does not.

That also raises the question how you get to the symbols after using
just $imgact/$imgfix. OK, there was a :-)
Continue reading on narkive:
Loading...