Oracle Automatic Storage Management Filter Driver (Oracle ASMFD)

Comments 0

Share to social media

Prior to Oracle Grid Infrastructure (GI) release 12.1.0.2, ASM Library (ASMLIB) was the only method to access storage devices by means of ASM Disks and Diskgroups. There were serious limitations to this method. The ASM disks were owned by GI home owner and both the owner and any users belonging to an operating system group designated as the OSASM group could read from and write to ASM disks using OS commands like strings, echo, dd etc. This led to compromising the security of data as well as accidental corruption of the data in the ASM disks and ASM disks themselves.

With Oracle Grid Infrastructure release 12.1.0.2, Oracle has introduced a new component called Oracle Automatic Storage Management Filter Driver (Oracle ASMFD) which is installed with an Oracle Grid Infrastructure installation. It is intended to overcome the limitations mentioned earlier and replace traditional ASMLIB. ASMFD is currently available only on the Linux operating system and can be completely managed by the ASMCMD command Line interface.

Oracle ASMFD is a kernel module that resides in the I/O path of the Oracle ASM disks. ASMFD uses the filter driver to validate write I/O requests to Oracle ASM disks. Any write I/O requests that are not issued by Oracle software (e.g. using dd command) are not committed to ASM disks. Thus it helps to prevent users, including those with administrative privileges, from inadvertently overwriting Oracle ASM disks, thereby preventing corruption of the data stored on ASM disk(s) within the disk group(s). In case ASM disks have been configured on disk partitions, the filter protects the area on the disk managed by Oracle ASMFD, assuming the partition table is left untouched by the user.

Besides, Oracle ASMFD eliminates the need to rebind disk devices used with Oracle ASM each time the system is restarted.

If you have an existing Oracle ASM library driver (Oracle ASMLIB) configuration, and you want to employ ASMFD, you would need to configure Oracle ASMFD. This will remove Oracle ASMLIB and Oracle ASM devices will be configured to use Oracle ASMFD. In this article, I will demonstrate configuration of Oracle ASMFD in a standalone environment.

Currently, I have Oracle ASMLIB configured on my standalone system. OS user oracle is the owner of both GI home and Database home.

Overview:

Implementation:

Verify that currently ASMLIB has been configured and ASMFD is not configured yet

We can verify that Oracle ASMLIB is configured and driver for oracleasm is currently loaded.

Let’s check the permissions and location of ASM Disks.

The ASM Disks are block devices in /dev/oracleasm/disks owned by the GI owner “oracle” user. OS user oracle and anyone belonging to OS group “dba” (which maps to OSASM privilege) can read from and write to ASM disks. Thus the ASM disks are vulnerable to accidental Disk and or Data corruption.

We can verify that ASMFD is not configured.

Create a table in an ASM tablespace

Let’s find out candidate disks which are not part of any disk group yet.

Migrate ASM disks to use ASMFD

Let’s find out disks in DATA and TEST disk groups

Let’s make a note of current disk discovery path. It currently points to ASMLIB disks.

Make sure ASM is using SPFILE

Now, let’s start with the migration.

Update the ASM Disk discovery path to enable ASMFD lookup

Once we label the disk, it will show up as AFD: and that name will be used for disk discovery.

AS GI owner , set the ASM discovery string to include AFD.* as well:

We have updated ASM disk discovery string. Now, when we configure ASMFD it would be able to discover and migrate the existing disks.

Bring down the Clusterware stack

Now, we are ready for the migration process.

Configure ASMFD

This step will deconfigure ASMLIB, configure ASMFD and migrate the disks from ASMLIB to ASMFD.

We can ignore the last error for now but we do have a working ASMFD now.

Note that the folder for oracleasm has been emptied and ASMFD has created a folder /dev/oracleafd where all the ASM disks are visible such that root is the owner of disks and only root can read from or write to ASM disks.

The disks can now be viewed from ASM Filter Driver Module.

We can verify that the configuration process has stopped the ASMLIB kernel module

We are almost done with the migration as ASMFD is loaded and the existing disks are already mapped. Once we start the Clusterware stack, we will update few configuration settings to make ASMFD persistent.

Start Clusterware stack

We can verify that driver for ASMFD has been loaded.

Verify that ASMFD has been successfully configured and ASM disks have been migrated

Set ASM_DISKSTRING and AFD_DISKSTRING to ‘AFD:*’

Currently, parameter ASM_DISKSTRING points to both ASMLIB and ASMFD disks. Since ASMLIB has been deconfigured, we can remove ORCL:* from the parameter so that the parameter points to ASMFD disks only.

We can also set discovery string for ASMFD disks to ‘AFD:*’

Validate that ASM Diskgroups have migrated and are using ASMFD

Validate if the diskgroups are migrated and using ASMFD

Verify that our data is intact after migration

Let’s explore the disks located under /dev/oracleafd/disks/ .

These are actually just the text files owned by root pointing to the actual disks on which the ASM disks are configured as opposed to ASMLIB disks which were block devices owned by GI owner.

Verify that when filter is enabled it does not allow OS commands to alter the contents of ASM disks

We can check that filtering is enabled on AFD disks.

Now non-root users have no way to read directly from ASM disks using OS command “strings”. Root user can still read the content of ASM disks cirectly.

For ASM disk writes, we get a layer of protection for both root and non-root users. I will demonstrate it for both “echo” and “dd” commands.

When we try to write to underlying disk using “echo” as a root user, although the echo command is successful, the I/O were rejected by ASMFD which can be confirmed by looking into /var/log/messages.

Similarly when we try to modify contents of ASM disk using ‘dd‘ command, GI owner is denied permission where command succeeds for root without any effect though as can again be verified from /var/log/messages.

Let us disable filter for all disks

Now that filter is disabled, let us try to perform write I/O on ASMDISK10.

It can be seen although non-root user can still not write to ASM disk but root user can alter the contents of ASM Disks leading to corruption of Data in the ASM Disks and ASM disks themselves.

Conclusion:

Oracle Automatic Storage Management Filter Driver (Oracle ASMFD) can overcome the limitations of and replace traditional ASMLIB. When filter is enabled,

– Contents of ASMFD disks can only be read using OS commands by root user

– Contents of ASMFD disks cannot be altered using OS commands by any user

Thus, any write I/O performed to ASM disks by will be validated by the filter and corruption of data on ASM disks by non-oracle software will be eliminated.

References:

Load comments

About the author