topic Re: Problem with protections when installing a shared image in Operating System - OpenVMS

Problem with protections when installing a shared image

Philip.Kenthp.com — Mon, 19 Jun 2006 20:00:04 GMT

I have a customer who is installing a shared image from a batch job submitted by the system account:

The only thing in the file is:
$ install create sys$share:ptcchlext/log

The output is:
DISK$ALPHASYS_732:.EXE
PTCCHLEXT;5
Entry access count = 0

Owner: [SYSTEM]
Protection: S:,O:RWE,G:,W:RE

They say that in the past, when the image was installed, the protection use to be:
S:RWE,O:RWE,G:RWE,W:RWE

Is there a way of setting the protection on this shared image at install or later to match this protection scheme?

Thanks

Re: Problem with protections when installing a shared image

Thomas Ritter — Mon, 19 Jun 2006 21:15:30 GMT

In our system startups we typically do this

$ file := SECRET.EXE
$ if f$search(file) .nes. ""
$ then
$ install replace 'file /head/privileged=(tmpmbx,netmbx,bypass,world,oper)
$ set file/acl=(id=[*],access=none) 'file
$ set file/acl=(id=[SUPPORT],access=read+execute) 'file
$ set file/prot=w:re 'file
$ endif

There should be enough here to provide ideas to customize the access.

Thomas.

Re: Problem with protections when installing a shared image

Wim Van den Wyngaert — Tue, 20 Jun 2006 02:46:28 GMT

Install doesn't modify protection.

May be the file was re-created by someone. With the default protection of his account.

Or may be normally the previous version existed and this time it didn't (prev version results in inherit of protection).

Wim

Re: Problem with protections when installing a shared image

Phillip Thayer — Tue, 20 Jun 2006 07:45:32 GMT

Philip,

Install doesn't set protections or ownerships of the file being installed. This is all determined by the file attributes. Check the file with a DIR/FULL and see if the file protections are different from what you want (S:RWE,O:RWE,G:RWE,W:RWE). If the file protection is not right then set it to what you need it to be.

Phil

Re: Problem with protections when installing a shared image

John Gillings — Tue, 20 Jun 2006 18:21:24 GMT

If I understand your question, you want to make sure the security of a specific file matches that of a previous version? Try this procedure (to be executed before installing the image):

checkprot.com
$ IF p1.EQS."" THEN INQUIRE p1 "File"
$ latest=F$SEARCH(p1-F$PARSE(p1,,,"VERSION")) ! Find latest version
$ previous=F$SEARCH(latest-F$PARSE(latest,,,"VERSION")+";-1") ! Find previous version
$ IF previous.NES."" ! If previous version exists
$ THEN ! Compare protection strings
$ IF F$FILE_ATTRIBUTES(latest,"PRO").NES.F$FILE_ATTRIBUTES(previous,"PRO")
$ THEN ! If not identical, propagate security from previous version
$ SET SECURITY/LIKE=(NAME='previous',CLASS=FILE) 'latest'
$ ENDIF
$ ENDIF

Note that this does a bit more than you asked - the entire security profile is copied from the previous version. One potential problem is if the protection masks are the same, but the ACL is different. You could fix that by unconditionally setting the security if the previous version exists. Only downside is you will do it every time, as long as the old file exists.

Re: Problem with protections when installing a shared image

Thomas Ritter — Sun, 02 Jul 2006 18:45:28 GMT

Phillip, were any of the tips here useful ? Has the problem been resolved ?

Re: Problem with protections when installing a shared image

John Gillings — Sun, 02 Jul 2006 23:59:11 GMT

Thomas,

The INSTALL symptom was a red herring. It appears there's a cosmetic bug in INSTALL which results in a nonsense owner/protection display. Consider:

$ INSTALL ADD image/LOG

To what do the "owner" and "protection" fields listed refer? There are no global sections, so they have no meaning.

A simple experiment, take an image owned by someone other than SYSTEM, change the protection to something unusual and execute the INSTALL ADD/LOG command. You'll probably find that neither owner or protection fields displayed match the file.

Now INSTALL REMOVE and ADD again, this time with /SHARE, which may create one or more global sections. Again the values displayed by INSTALL are junk. Use SHOW SECURITY/CLASS=SYSTEM_GLOBAL_SECTION to examine the "correct" owner and protection masks - they are correct. Use INSTALL LIST/GLOBAL/FULL to see that INSTALL displays them incorrectly.

Bottom line is the symptom is purely cosmetic, and has no influence on the accessibility of the image.

INSTALL ADD of an executable image makes very little sense (a non-shared INSTALL is only really useful for a shareable image).
Having WORLD:WRITE protection on any installed image is even more questionable.

(I believe Philip's underlying problem has been resolved)

Re: Problem with protections when installing a shared image

Ian Miller. — Mon, 03 Jul 2006 02:58:15 GMT

Is the junk display because INSTALL is showing the contents of GSD$L_PROT instead of from the ORB?

Re: Problem with protections when installing a shared image

Philip.Kenthp.com — Tue, 04 Jul 2006 19:40:12 GMT

Yes the problem was resolved.
The customer was having other problems that they had not informed me of, and I was working with a resident engineer who had been there for 11 months and assumed that his understanding of the issues was sufficient. I was wrong. The protection mask on the installed image had no bearing on resolving the problem.

Phil

Re: Problem with protections when installing a shared image

Thomas Ritter — Wed, 05 Jul 2006 07:04:29 GMT

Philip,

please view

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

about thanking those that helped.

Re: Problem with protections when installing a shared image

Philip.Kenthp.com — Wed, 05 Jul 2006 08:23:27 GMT

Closing the thread.

Thanks for the help