Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

How come VMS Perl requires user written extensions to be installed?

SOLVED
Go to solution
Tim Yeung_1
Frequent Advisor

How come VMS Perl requires user written extensions to be installed?

For user written Perl extensions, I get the error "privileged image must be installed" error when I run it. After installing it via the INSTALL utility, then it works.

This becomes a problem for many users because they don't have privileges to install programs. Is there a way around this problem of having to INSTALL Perl extensions on VMS?
11 REPLIES
Karl Rohwedder
Honored Contributor
Solution

Re: How come VMS Perl requires user written extensions to be installed?

Tim,

is your PERL image installed with privs?

See HELP/MESS PRIVINSTALl for more info.

regards kalle
Hein van den Heuvel
Honored Contributor

Re: How come VMS Perl requires user written extensions to be installed?

Once you installed it (with privs), it is avaiable to all. So the other users should have no problem right?
What is the extetntion going to do? Does it require privs? Don't you agree teh system shoudl do something special to allow 'other' users to get access to privved stuff?

fwiw,
Hein.
Tim Yeung_1
Frequent Advisor

Re: How come VMS Perl requires user written extensions to be installed?

PERLSHR and PERL.EXE are not INSTALL'ed.
The user extensions don't need privileges.
But when the extension is invoked, the errors says privileged images must be installed. So I install PERLSHR, PERL.EXE, and the extension without any privileges - basically just INSTALL without any qualifiers. Then the extension works perfectly. I'm trying to avoid having to grant privileges to software developers.

Thanks.
John Gillings
Honored Contributor

Re: How come VMS Perl requires user written extensions to be installed?

Tim,

>PERLSHR and PERL.EXE are not INSTALL'ed.

Standard reminder... there is NO SUCH THING as a "privileged shareable image".

First the simplest possibility - make sure PERLSHR.EXE and PERL.EXE have protection W:RE not W:E - NOREAD images cannot activate untrusted shareable images.

Check out the entire shareable image dependence tree for PERL.EXE and see what other images are activated. The presence of user written system services (UWSS), can, in some cases, put the image activator into "paranoia" mode, where it insists on all activated images being "trusted" - meaning INSTALLed and referred to only by trused logical names (EXEC mode logical names in logical name tables defined in the search path of the EXEC mode definition LNM$FILE_DEV in LNM$SYSTEM_DIRECTORY). PRIVINSTALL is the error message issued if paranoia isn't satisfied.

This behaviour can sometimes result in the necesity to INSTALL a whole set of images, as the paranoia propagates. It's also arguably unnecessary as it shouldn't be possible to get from the UWSS into some random shareable image activated afterwards, and besides, if that were possible, what's to stop it from getting into some random shareable image activated BEFORE paranoia mode was triggered, and therefore activated without needing to be trusted?

See attached IMAGETREE.COM to examine the dependencies of an image. You may need to use "SET WATCH/CLASS=MAJOR FILE" to trace image activations, in case the image which triggers the paranoia is activated dynamically.

If you can identify which image is the trigger, you may be able to work out a way around it. If it's just a simple protection problem, give all legitimate users READ access to the image and you should be set.

(and cue Mr Maher to rant about Steve Hoffman's "crime of the century" and invent another way to misspell my name :-)
A crucible of informative mistakes
Craig A Berry
Honored Contributor

Re: How come VMS Perl requires user written extensions to be installed?

The general answer to the question in your subject line is "they don't." This is not to deny that you have a problem, but it's pretty unlikely to have anything to do with Perl per se, though it is possible it has something to do with locally written extensions. I think John probably has the best suggestions for how to track this down. In particular, check the definition(s) of the PERLSHR logical name; if you've got it defined /system/exec try skipping the /exec. Consider posting the results of:

$ show logical/full *perl*

FWIW, one of the earliest things that happens when Perl starts up is that it disables all image privs. I don't think that's relevant to Tim's problem, but I mention it lest someone reading this thread end up with the mistaken impression that installing PERL.EXE with privs actually does something.
Craig A Berry
Honored Contributor

Re: How come VMS Perl requires user written extensions to be installed?

John,

IMAGETREE.COM looks like a nifty utility, but Perl extensions are normally loaded at run-time using lib$find_image_symbol, so if I understand what's it's doing correctly it may not help.

Tim, to get some run-time debugging output about Perl extension loading, define the following:

$ define PERL_DL_DEBUG 10

You can also have a look at the source code of the extension used to load extensions here:

http://public.activestate.com/cgi-bin/perlbrowse/f/ext/DynaLoader/dl_vms.xs
Tim Yeung_1
Frequent Advisor

Re: How come VMS Perl requires user written extensions to be installed?

Thanks for all the suggestions. I've tracked the problem to the customer linking their Perl extensions with a UWSS. If they didn't link with the UWSS, then everything worked without being INSTALL'ed.

However, their application requires linking with the UWSS, so I guess they are stuck with having to install all their Perl extensions.

Thanks again.

Tim
John Gillings
Honored Contributor

Re: How come VMS Perl requires user written extensions to be installed?

Tim,

> I've tracked the problem to the customer
>linking their Perl extensions with a UWSS.

This doesn't sound right to me! It should be possible to call an installed UWSS without having to be installed yourself. That's the whole point of UWSS! To give non-privileged programs controlled access to privileged operations WITHOUT needing to be privileged or trusted. There's something deeper going on.

If you can't figure out what's wrong with the UWSS or the way you're linking against it, you may be able to isolate yourself from it by building a shareable image which exports all the routines from the UWSS but isn't linked against it. Inside the shareable image, each routine has a first time flag that calls LIB$FIND_IMAGE_SYMBOL to activate the UWSS at run time, find the address of the UWSS routine and call through. That way you defer activating the UWSS until everything else is done, which should avoid triggering paranoia mode when activating your Perl extension. (note - do NOT use a LIB$INITIALISE section to implement the LIB$FIS, as that will do the activation up front, rather than at the first call)
A crucible of informative mistakes
Tim Yeung_1
Frequent Advisor

Re: How come VMS Perl requires user written extensions to be installed?

You are correct, John Gillings, it wasn't the UWSS. Their linking mechanism is much more complicated than I first thought.

I removed the UWSS from the link options file, but it didn't fix the. They also link with a bunch of shareable images, some of them are installed with privs.

I don't think there is a way out of this.

Thanks

Tim

Jan van den Ende
Honored Contributor

Re: How come VMS Perl requires user written extensions to be installed?

Tim,

On how to say "thanks" in these forums, please review

http://forums1.itrc.hp.com/service/forums/helptips.do?#33

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
John Gillings
Honored Contributor

Re: How come VMS Perl requires user written extensions to be installed?

Tim,

>I don't think there is a way out of this.

There's ALWAYS a way out! You just have to understand your objectives, and what's really going on :-)

> They also link with a bunch of shareable
>images, some of them are installed with
>privs.
>
This concerns me. SHAREABLE images should not be installed with privilege. It doesn't do anything useful, but can cause image activation problems (like yours). See:

$ HELP INSTALL ADD/PRIV - in particular the bit that says:

o The /PRIVILEGED qualifier applies only to executable images.

Just to make sure we're prefectly clear on this, if you RUN the image you can give it privileges, if you LINK against an image, you CANNOT give that image privileges, and should not INSTALL the image with /PRIVILEGE.

Try removing the privileges from ALL shareable images you link against and try again. This should not break anything. Ask anyone who objects to explain exactly what /PRIVILEGE is buying them other than problems. As I said in my first response:

Standard reminder... there is NO SUCH THING as a "privileged shareable image".


(OK, there's ONE potential use for a shareable image installed with privilege, that's when it also contains a transfer address - kind of a hybrid executable image and shareable image - it is possible, but rarely done in practice, and not recommended. In that case if you INSTALL the image with privilege, you'll get the privileges if you RUN the image, but not if it's activated as a shareable image. IF you have one of these beasts, it's a simple matter of splitting up the main program part and shareable routines part, then linking them separately. As far as I know, this, and fanatical adherance to upwards compatibility, are the only reasons the /PRIVILEGE qualifier hasn't been blocked for shareable images in INSTALL)
A crucible of informative mistakes