Installing the Audit Vault Agent Under Its Own OS User Account

For environments that require more separation of duties, you can install the Audit Vault Agent under it’s own OS user account instead of under the OS user account that owns the Oracle software installation.

You have two options:

Traditional Unix permissions
POSIX access control lists (ACLs)

Traditional Unix Permissions

This is the simplest option. It involves adding the Audit Vault Agent user avagentosuser to the same primary group (usually oinstall) as the Oracle software owner. Sometimes the database does write out an audit file without group read access. This is easy to maintain with the chmod g:rx command.

POSIX ACLs

POSIX ACLs let you set privileges on files and directories that override traditional UNIX permissions.

Here are some points to consider before choosing this approach:

If you’re using Oracle Exadata, when a quarterly bundle patch is applied, the file access control list (FACL) packages are removed (or have to be removed to avoid bundle patch conflicts). When FACL packages are removed, the existing FACLs that are set stay in effect.
If the DBAs move any directory in the audit_file_dest path, the FACLs break. A simple action like mv audit audit.old; mkdir audit would break the FACL on that directory.
The FACL command to setFACL can only be run by root.

If the FACLs are broken (or FACL binaries or packages are missing after a bundle patch is applied) and the DBA or Audit Vault Server administrator must work with a system administrator with root access to resolve the issue, then audit collection may no longer be in near real time.
The /etc/fstab mount point must have acl set so the ACLs will be applied to that file system and remounted.

You can apply FACLs to the directory to allow access for a specific user. Any new file that’s created in that directory (like a new audit record) will have the FACL permissions. Any audit file that exists in the directory before you apply the FACL will not have the FACL permissions, so you need to apply the setFACL command to each file individually.

Each directory in the fully qualified path to the audit directory must have the FACL set so that the dedicated user can traverse the path to the audit files.

Example C-1 Applying FACLs

This example uses the root user and an OS user named avagent.

Between running the UNIX commands as root, you can user your OS user account to see the results.

Run the following commands as root:

mkdir -p /tmp/dir1/dir2/audit

mkdir -p /tmp/dir1/dir2/audit2

touch /tmp/dir1/dir2/audit/file1

touch /tmp/dir1/dir2/audit2/file2

chmod -R 750 /tmp/dir1

Grant access to the /tmp/dir1/dir2/audit directory only for the avagent OS user. You have to do this for every directory (just like you would with chmod 750, for example).
```
setfacl -m u:avagent:rx /tmp/
```
```
setfacl -m u:avagent:rx /tmp/dir1
```
```
setfacl -m u:avagent:rx /tmp/dir1/dir2
```
```
setfacl -m u:avagent:rx /tmp/dir1/dir2/audit
```
The avagent OS user can now access the /tmp/dir1/dir2/audit directory but not the /tmp/dir1/dir2/audit2 directory, because no FACL is applied there.
To see whether an FACL is applied on a file or directory, use the following command:
```
getfacl <file/directory>
```
Specify that any new files that are created in the /tmp/dir1/dir2/audit directory will have the rx access for the avagent OS user.
```
setfacl -dm u:avagent:rx /tmp/dir1/dir2/audit
```
To verify that the default information is set up correctly, use the following command:
```
getfacl /tmp/dir1/dir2/audit
```
To test the preceding settings, create a new file in /tmp/dir1/dir2/audit.
```
echo "test" > /tmp/dir1/dir2/audit/file3
```
The avagent OS user can access file3 but not file1.

Use getfacl to check the differences between the files.

getfacl /tmp/dir1/dir2/audit/file1

getfacl /tmp/dir1/dir2/audit/file3

To resolve files that didn’t have a FACL applied before setfacl -d [default] was set up to apply to any new file in the directory, apply the FACL to the files.
```
setfacl -m u:avagent:rx /tmp/dir1/dir2/audit/file1
```
You can also use wildcards. For example:
```
setfacl -m u:avagent:rx /tmp/dir1/dir2/audit/*
```
To test moving files into the /tmp/dir1/dir2/audit directory, run the following commands:
```
mv /tmp/dir1/dir2/audit2/file2 /tmp/dir1/dir2/audit/
```
```
getfacl /tmp/dir1/dir2/audit/file2
```
The moved file doesn’t have the FACL applied because it wasn’t created in the directory when the setfacl -d [default] was set up, so you have to apply the FACL to the moved file.
```
setfacl -m u:avagent:rx /tmp/dir1/dir2/audit/file2
```