Problem with protections when installing a shared image

[Philip.Kenthp.com]

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

[Thomas Ritter]

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]

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

[Phillip Thayer]

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

[John Gillings]

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.

[Thomas Ritter]

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

[John Gillings · Accepted solution]

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)

[Ian Miller.]

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

[Philip.Kenthp.com]

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]

Philip,

please view

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

about thanking those that helped.

[Philip.Kenthp.com]

Closing the thread.

Thanks for the help