Backup and 000000.dir

[Wim Van den Wyngaert]

A user with netmbx, tmpmbx, grpprv and grpnam
tries to do a backup of dsa2:[x.y]toto.dat x:toto.dat. The backup works fine.

But in audit I get a READ access violation on dsa2:[000000]000000.dir. Which has W:E.

Why is backup doing this read and how to solve this problem ?

Wim

[Karl Rohwedder]

Wim,

what was the exact backup command and how is logical X defined?
I am not able to reproduce this.

regards Kalle

[Wim Van den Wyngaert]

backup dsa2:[x.y]toto.dat ops$mail:*.*;

and ops$mail [exec] ops$root:[mailfiles] /sys
and ops$root [exec] disk:[operations.] [conc] /sys


But I tried to replace dsa2:[x.] by a concealed device and then it works fine without alarm.

It seems that backup needs read access on all directory levels ? Then why if it also works without the access.

Wim

[Wim Van den Wyngaert]

No experience in reading this garbage but here is the set watch output.

Wim

[Wim Van den Wyngaert]

Note : the set watch was done with a system user.

[John Gillings · Accepted solution]

Wim,

The purpose of BACKUP is to reproduce the set of files being backed up. This includes all the attributes of all directories in the entire directory tree.

If BACKUP can't read the attributes, a directory won't be physically included in the saveset - though its existence can still be inferred from the filespecs of the saved files. On restore BACKUP will create *A* directory, with the correct name, but with whatever default owner, protection, version limits etc... are applicable. Your SET WATCH output shows BACKUP reading the directory attributes.

%XQP, Thread #0, Volume protection: Access requested: 00000001, Status: 00000001, PrvUsd: 00000000
%XQP, Thread #0, File protection (4,4,0): Access requested: 00000001, Status: 00000001, PrvUsd: 00000001
%XQP, Thread #0, Read attributes: File header 000000.DIR;1 (4,4,0)
%XQP, Thread #0, Read attributes: Back link 000000.DIR;1 (4,4,0)
%XQP, Thread #0, Read attributes: ASCII file name, type & version 000000.DIR;1 (4,4,0)
%XQP, Thread #0, Access 000000.DIR;1 (4,4,0) Status: 00000001

In your case the first BACKUP command implicitly references the "real" 000000.DIR, whereas the concealed device skips it - instead it references a "virtual" 000000.DIR, being the root of the concealed device (to which it DOES have read access).

By default, the 000000 directory usually has W:E access - this allows a non-privileged user to traverse the directory, but not to search it. Normal security practice. It also blocks non-privileged users from reading the directory attributes.

So, your BACKUP is working, except that it can't save 000000.DIR explicitly. The BACKUP command won't give you any errors, and the restore will work correctly (since you won't need to restore 000000.DIR, it doesn't matter that its attributes weren't saved), but you will correctly see a read failure audit on the directory, because that's what you've asked for. However, if you were to perform a full backup of this disk, with the same non-privileged user, and your 000000.DIR has non-default attributes, the restore wouldn't reproduce it.

I'm not sure which part of this you consider a problem. The BACKUP is doing exactly what you asked, within the constraints you've imposed on it.

You can either ignore the audit, give your process READ access to 000000.DIR, use the concealed device to skip 000000.DIR or increase the privileges of the process.

[Wim Van den Wyngaert]

John,

This is what I suspected. I didn't think of the fact that READ access is required to get the full information of the file.
I granted READ access.

Thx

Wim