Backup question

[Jimson_1]

Hi,

When using the BACKUP utility to backup a file to a saveset, is it also possible to backup the file's security profile?

This doesn't appear to happen by default. Instead it takes the default profile of the parent directory.

Anyone know how to do this?

[The Brit]

Hi James,

Using /By_Owner=Original as an "Output Qualifier" will cause the restored files to have the same ownership as the original files, however I dont know if this extends to the protection string. I am pretty sure that "Identifiers" are not propagated.

Dave

[Shriniketan Bhagwat]

Hi JamesP,

Do you mean SUBSYSTEM ACE as security profile of the file?
BACKUP behavior for SUBSYSTEM ACE is as below.

(1) BACKUP saves the SUBSYSTEM ACE in the save set.
(2) BACKUP restores the SUBSYSTEM ACE if the account under which it is being run holds the subsystem identifier.
(3) BACKUP does not restore the SUBSYSTEM ACE if the account under which it is being run does not hold the subsystem identifier, even if the account is privileged.

Regards,
Ketan

[P Muralidhar Kini]

Hi,

If you look at the DCL help for BACKUP/BY_OWNER

BACKUP

/BY_OWNER

/BY_OWNER[=[uic]]
/BY_OWNER[=option]

As an input file-selection qualifier, /BY_OWNER causes BACKUP
to process files owned by the specified UIC. Specify the UIC as
octal numbers or in alphanumeric format (in the form [g,m]). Note
that the UIC specification must include the brackets. UIC formats
are described in the OpenVMS User's Manual. If you specify this
qualifier without a UIC, the default UIC is the current process
UIC. If you do not specify this qualifier, BACKUP processes all
files on the volume.

As an output file qualifier, /BY_OWNER redefines the owner UIC
for each file restored during the operation. As an output save-
set qualifier, /BY_OWNER specifies the owner UIC of the save set.
If you omit the /BY_OWNER qualifier, the save set receives the
UIC of the current process. To use /BY_OWNER as an output save-
set qualifier, you must have the SYSPRV user privilege or the UIC
must be your own.


>> Using /By_Owner=Original as an "Output Qualifier"
Yes, thats right. Looks like only the UIC gets propogated and not the
security profile.

Regards,
Murali

[Jimson_1]

Shriniketan,

When I referred to security profile, I meant the protection string and any ACL identifiers.

[Shriniketan Bhagwat]

Hi James,

As the others in the notes replied, you can use /BY_OWNER=ORIGINAL qualifier to restore the files to the same ownership. And with respect to ACL identifier of the file, BACKUPâ s behavior for ACL identifier is same as subsystem ACE as explained in my previous reply. You should use the same account which holds the identifier to restore the file.

Regards,
Ketan

[The Brit]

Be aware however, I believe that backup copies the identifier value and not the Identifier name. The system receiving the restore must have the identifiers defined in the UAF, and they must have the same values as the original system.

This does not happen automatically, and doing it manually can be a pain in the proverbial.

On the receiving system, if the identifiers already exist but have the incorrect values, then they need to modified using the

UAF> modify /id /value=
(see help)

if they dont exist, they should be created using

UAF> add /id /value=
(see help)

Dave

[Steven Schweda]

It may be worth noting that BACKUP normally
saves these data when creating a save set,
but /INTERCHANGE can stop it. What happens
to these data when the save set is restored
is another question.

[Jan van den Ende]

Dave (the Brit) gave essentially the whole story. BACKUP _DOES_ save the (whole) security profile (exception: see Steven's answer). Upon restore, the security profile ONLY gets restored if /BY_OWNER=ORIGINAL (or /OWNER=ORIGINAL, as it used to be called, which still works of course, this being VMS).
And again Dave is right: the NUMERIC value of any identifiers gets restored, and if the restore is to a system that has a different RIGHTSLIST, that may be VERY inconvenient.
That is exactly the reason that we had a really strict protocol for translating alphanumeric names to hex values - implying that whenever any installation generated its own identifier, its value is immediately changed to the value calculated for that name.

hth

Proost.

Have one on me.

jpe

[Jon Pinkley]

Shriniketan Bhagwat wrote on Jun 10, 2010 11:39:20 GMT

(1) BACKUP saves the SUBSYSTEM ACE in the save set.
(2) BACKUP restores the SUBSYSTEM ACE if the account under which it is being run holds the subsystem identifier.
(3) BACKUP does not restore the SUBSYSTEM ACE if the account under which it is being run does not hold the subsystem identifier, even if the account is privileged.
----------
Where is this documented? (backup, system security, somewhere else?)

I just tried this and it is true for non-image restores. I don't think it is backup that is doing anything special to limit what can be restored, my guess is that it is the XQP. Using set security/acl gets a similar error if the process is not holding the subsystem identifier.

An image restore can restore these ACLs without any problem. But in this case, the XQP is not involved, as the disk is mounted /foreign.

Summary: Process with all privs but not holding subsystem identifier will get this message when restoring the file to a XQP mounted disk:

OT$ backup test.bck/save [.itrc]/own=orig/ver/log
%BACKUP-I-SSINOTGRANTED, protected subsystem identifier not granted to this account; ACL not modified for ROOT$USERS:[JON.ITRC]TEST.
EXE;10
%BACKUP-S-CREATED, created ROOT$USERS:[JON.ITRC]TEST.EXE;10
%BACKUP-I-STARTVERIFY, starting verification pass at 11-JUN-2010 02:03:57.76
%BACKUP-S-COMPARED, compared ROOT$USERS:[JON.ITRC]TEST.EXE;10
OT$ set security/class=file /acl=(subsystem,ident=JON_TEST$SUBSYSTEM,attr=resource) ROOT$USERS:[JON.ITRC]TEST.EXE;10
%SET-F-WRITEERR, error writing ROOT$USERS:[JON.ITRC]TEST.EXE;10
-SYSTEM-F-SSINOTHELD, protected subsystem identifier not held; ACL not modified
OT$

An image restore will restore the subsystem ACE even if the process does not hold the protected subsystem identifier.

For more details see attachment.

Jon

[Jimson_1]

Hi Guys,

Thanks for all your replies.

I see my problem now.
The parent directory to where I want to restore my file, has an ACE with the SAME IDENTIFIER NAME, but different access types.

So, as one of you mentioned above, the file is restored with this ACE.

If I remove the parent directory's ACE (or change the identifier's name) the file is restored with the original ACE and its access types.

Problem solved.
Thanks.

[Shriniketan Bhagwat]

Hi Jon,

This behavior of BACKUP about ACE is not documented in any document. This is what I found the BACKUP code is doing for non image BACKUP. Yes, image BACKUP will restore entire disk with ACE without any problem since the disk mounted foreign where XQP will not get involved.

James,

Please refer the below link to thank the forum.
http://forums11.itrc.hp.com/service/forums/helptips.do?#33

Regards,
Ketan

[Jon Pinkley]

The behavior of the backup /interchange qualifier is not well documented, especially its effect when used on a restore operation. The following can be verified by experiment, and has been true for at least VMS V5 through 8.3.

When /interchange is used to create a save set, the ACLs are not copied into the save set.

When /interchange is used to create (non-save set) files on a disk (either restoring from a save set or when copying files from disk to disk), the /interchange qualifier prevents backup from specifying any protection or ACL, and the RMS default behavior dictates what the protection of the file will be. In other words, the behavior will be similar to COPY, but the file ownership still behaves the same as if /interchange was not used. The file protection mask is determined like copy, i.e. if a previous version of the file exists, then the new version will copy the protection from the previous file version, else if the target directory has a default_protection ACE, then that is used, else the processes RMS default protection is used. If the output file has an ACL, it came from a previous version of the file, or an ACE in the target directory that had options=default .

/interchange has no effect on the owner of the file, as backup always explicitly sets the owner of the created file. The owner will be set to the original owner (if /by_owner=original or /owner=original was specified), the UIC of the process running backup (the default behavior), the owner of the target directory (if /by_owner=parent specified), or a user specified UIC (if /by_owner=[UIC] specified). There is no way to get the behavior of COPY, which will attempt to preserve the ownership of the file, i.e. if there is a previous version of the file, and the process creating the file has the rights to specify this as the owner, then the new version of the file will have the same ownership as the previous version. This behavior is the default RMS behavior, and has been around since either V3 or V4 (I can't remember when it changed, it was a long time ago).

There is no backup /by_owner=rms_default. I really wish that was the default backup behavior, because if a privileged user uses backup to copy to another users directory and does not specify /owner=parent, then it is likely that the owner of the directory will not have the ability to do much with the file. But BACKUP's default behavior is extremely unlikely to change. I do wish there was a way to have backup use the rms_default behavior, as this is usually better than /own=parent.

Jon

[Jon Pinkley]

James,

What evidence do you have that the problem you posed exists, and that the removing an ACL on the target directory had any effect on the ACL of the restored file?

I can't reproduce the "problem" you originally described (backup not restoring the original ACL) unless the /interchange qualifier is used.

But if the /interchange qualifier is used, then the ACL is completely removed, and the only way an ACL will be applied to the restored file is if there is an ACL on the target directory, and that ACL has at least one ACE with the "options=default" attached.

Can you please provide the commands you used, and the version of VMS that was used?

Can you also provide an example of how the parent directory's ACL having an ACE with the same identifier makes any difference?

If you don't respond, we will have to assume that you can't reproduce the problem you were describing and that the ACL had no effect on what backup did.

See attached zip file that has a command procedure (renamed with .txt and a log file) showing the testing I did. The command proceedure should work as is if you want to test it. It will create subdirectories [.itrc1] and [.itrc2] while running.

Jon

[Shriniketan Bhagwat]

Hi Jon,

BACKUP does not copy the ACL if the /INTERCHANGE qualifier is used. As I said earlier. BACKUP saves ACL in the saveset and to restore the ACL, the account which holds the same identifier should be used. This is applicable for BACKUP copy operation also.

BACKUP copy or restore operation does not apply the ACL of the target directory to the newly copied or restored file. Instead it inherits the all attributes including ACL (if the account which holds the same identifier is used to restore) and other security characteristics from the source file. This is because the file is represented by the attributes of its process and its source. After the BACKUP copy operation the ACL and other security characteristics for the newly created file should be added/modified by the user accordingly.

Regards,
Ketan

[Jon Pinkley]

Ketan,

Can you provide an example where holding the identifier is required to copy an ACL with backup, other than when a subsystem identifier is involved?

Jon

[Shriniketan Bhagwat]

Hi Jon,

I mean account which holds the subsystem identifier as identifier in my previous update. Sorry for not being so clear in the update.

Regards,
Ketan