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

Problem with protections when installing a shared image

SOLVED
Go to solution
Philip.Kenthp.com
Occasional Visitor

Problem with protections when installing a shared image

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
10 REPLIES
Thomas Ritter
Respected Contributor

Re: Problem with protections when installing a shared image

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.
Wim Van den Wyngaert
Honored Contributor

Re: Problem with protections when installing a shared image

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
Wim
Phillip Thayer
Esteemed Contributor

Re: Problem with protections when installing a shared image

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
Once it's in production it's all bugs after that.
John Gillings
Honored Contributor

Re: Problem with protections when installing a shared image

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.
A crucible of informative mistakes
Thomas Ritter
Respected Contributor

Re: Problem with protections when installing a shared image

Phillip, were any of the tips here useful ? Has the problem been resolved ?
John Gillings
Honored Contributor
Solution

Re: Problem with protections when installing a shared image

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)
A crucible of informative mistakes
Ian Miller.
Honored Contributor

Re: Problem with protections when installing a shared image

Is the junk display because INSTALL is showing the contents of GSD$L_PROT instead of from the ORB?
____________________
Purely Personal Opinion
Philip.Kenthp.com
Occasional Visitor

Re: Problem with protections when installing a shared image

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
Thomas Ritter
Respected Contributor

Re: Problem with protections when installing a shared image

Philip,

please view

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

about thanking those that helped.

Philip.Kenthp.com
Occasional Visitor

Re: Problem with protections when installing a shared image

Closing the thread.

Thanks for the help