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

[Tim Yeung_1]

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?

[Karl Rohwedder · Accepted solution]

Tim,

is your PERL image installed with privs?

See HELP/MESS PRIVINSTALl for more info.

regards kalle

[Hein van den Heuvel]

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]

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]

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 :-)

[Craig A Berry]

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]

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]

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]

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)

[Tim Yeung_1]

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