[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxaxp::vmsnotes

Title:VAX and Alpha VMS
Notice:This is a new VMSnotes, please read note 2.1
Moderator:VAXAXP::BERNARDO
Created:Wed Jan 22 1997
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:703
Total number of notes:3722

461.0. "Backup not inheriting default ACLs" by DSC000::CWINPENNY () Mon Apr 14 1997 07:07

    
    With reference to notes 946 and 1219 in the V12 archive.
    
    Seeing as how a normal installation kit will use VMSINSTAL callbacks
    and the PROVIDE_FILE callback uses BACKUP to copy files from its
    workspace to the target directory, has the impact of this 'bug fix',
    ie. no longer inheriting the target directory's ACEs, been fully
    investigated or was it even considered before changing the
    functionality?
    
    Considering the number of kits that have so far relied on the 'old'
    functionality what can be done for these kits that no longer work?
    
    Please don't suggest that I use BACKUP/INTERCHANGE, I am only using a
    tool over which I have no say in the modification of. If anybody knows
    of a way to have VMSINSTAL enhanced to compensate for the current
    functionality of BACKUP then I would be happy to hear of it.
    
    Chris
T.RTitleUserPersonal
Name		DateLines
461.1VMSINSTAL Protection Defaults...XDELTA::HOFFMANSteve, OpenVMS EngineeringMon Apr 14 1997 10:4516
    Use the SECURE_FILE and SET_ACL callbacks.

    Kit installations have traditionally installed without any sort
    of protection inheritence and has deliberately overridden any
    sort of "odd" disk structure protections -- this decision has
    been a source of friction between the OpenVMS engineers and the
    DECinspect folks, as has been discussed (at length) previously.
    It has been intended to avoid seriously "odd" problems that can
    result from incorrect protections, and the difficulty in
    re-establishing (and then testing) any non-default (unusual) file
    protection schemes.

    (See the KITINSTAL documentation around default protections.
    Please QAR the lack of documentation around ACL processing.)
461.2AUSS::GARSONDECcharity Program OfficeMon Apr 14 1997 22:4112
    re .0
    
    I use the C option on all PROVIDE_FILEs that are going into application
    trees. Whether this is strictly dependable behaviour I don't know but
    it has the desired effect.
    
    As .1 says, broadly speaking one is not supposed to rely on any
    security attributes propagating from the kit file to the destination
    file or from the destination environment to the destination file.
    Instead one is supposed to set, *in the kit* via the relevant callbacks,
    the precise security attributes that each file requires in order that the
    product is secure and yet operational.
461.3DSC000::CWINPENNYTue Apr 15 1997 12:4111
    
    Thanks,
    
    The 'C' option on provide file is not, I have been told, dependable. I
    can't see any reason why not but then again I couldn't see any reason
    why backup wouldn't be either.
    
    SECURE_FILE is only for protection not ACLs so it looks as if I'll
    have to use the proverbial hammer and use the SET_ACL callbacks.
    
    Chris