Immutability and appendOnly features in GPFS 3.4v on AIX

Immutable retention of your business data to help meet regulatory compliances and security needs

Protect your business data on IBM AIX® systems using immutability and appendOnly features supported by IBM® General Parallel File System (IBM GPFS™) V3.4 ensuring compliance to various government regulations. Having rich set of command line interfaces, GPFS allows you to set appropriate restrictions to your business audit files, health center records and log files in order to effectively secure them from being tampered with or accidentally deleted. This article illustrates how to make use of immutability and appendOnly restrictions offered by IBM GPFS V3.4 to protect your AIX data.

Share:

Sandeep Ramesh Patil (sandeep.patil@in.ibm.com), Senior Software Engineer, IBM

SandeepSandeep Ramesh Patil is a Senior Software Engineer for the IBM India Software Labs. He has worked for IBM for the past twelve years, focusing on Scale Out Network Attached Storage (IBM SONAS), distributed technology including DCE, SARPC, and security products such as the IBM Network Authentication Services (IBM Kerberos). He is an IBM developerWorks Master Author and IBM Master Inventor. Sandeep holds a BE degree in computer science and engineering from the University of Pune, India. You can contact him at sandeep.patil@in.ibm.com.



Ujwala P Tulshigiri (ujwala.tulshigiri@in.ibm.com), Software Developer

UjwalaUjwala P Tulshigiri is a Software Developer for the IBM India Software Labs. She has worked on system health monitoring of SONAS. She was part of Extreme Blue internship project named “Enabling ODF for Social Collaboration with Composite Application and Mashups.” Ujwala has completed a B.Tech in Computer Science from the College of Engineering, Pune (COEP). You can contact her at ujwala.tulshigiri@gmail.com.



30 April 2012

Also available in Chinese Russian

Introduction

The IBM General Parallel File System (GPFS) is a shared disk clustered file system, typically used in high performance computing. GPFS facilitates with high speed concurrent file access in a clustered environment. One of the main characteristics of GPFS that helps foster performance is its ability to strip blocks of data from the same file across different disks in a cluster and execute the read and write cycles in parallel. In addition, it provides various features like logging of metadata to recover from node failure, snapshot facility to preserve the file system data state at a single point of time, data replication in case of system failure, high availability of data and scalability. Hence traditionally, GPFS is used in supercomputer-like environments and its deployment is seen in many of the top supercomputers in the world.

In recent times, the use of GPFS is becoming popular even in day-to-day business applications. With the latest releases, GPFS has been enhanced with many features, which help deploy information lifecycle management functionality and even aid in adhering to various regulatory compliances. Because GPFS is available for AIX as well as Linux® clusters, it can help leverage these features to applications and storages running over these flavors of UNIX®. Facility to set immutability and appendOnly flags for files is one of the new and interesting features supported in GPFS V3.4 for AIX. Immutability typically means to protect the files or data from tampering and malicious data insertion. In other words, immutable files can't be deleted or changed even by the super user or root of the system. Similarly, setting the appendOnly flag to a file restricts the users to modify its content but at the same time allows appending data to the same. Such facilities are typically required in adherence of various compliances like Health Insurance Portability and Accountability Act (HIPAA) in the health care industry, Federal Financial Institutions Examination Council (FFIEC) in the financial sector or in defense-like applications. (For additional information on regulatory compliances, see Resources.)

In this article, we will explore the immutable and appendOnly file features for AIX available through GPFS V3.4. The article will explain different file operations available with these features and how they can benefit businesses to ensure secure and tamper-proof environment mandated by compliances.


Need for immutability

Many times, files stored on a file system contain confidential data that needs to be secured all the time from data corruption and deletion as well as erroneous data insertion by unauthorized user or sometimes even by root. Some businesses have the need for Write Once Read Many times (WORM) like facility over files, whereas some of the compliances for industries like HIPAA mandate the tamper proof facility for various kind of files like the business audit files, log files, health records etc. Immutability is a technology which ensures the security of data from damages and protects it from tampering. This technology is also called content integrity verification.

After a file is marked as immutable, it cannot be modified. However, files used for logging continuously grow in size. In such cases, to maintain the integrity of data, it is required to allow user to append data denying other privileges like changing access control lists (ACLs) or owner, editing or deleting the file.

Immutability in UNIX

In traditional UNIX file systems, files are made immutable by original owner or any centralized archive process in system by using the chmod command, which removes users write permission from ACLs of a file so that the file becomes inaccessible and cannot be modified. IBM GPFS provides many more options for immutability and appendOnly feature and allows the user to choose them as per their needs.


Immutability and AppendOnly features in GPFS

To prevent the files from being changed or deleted accidentally, GPFS provides two flags named immutable and appendOnly. In this article, we study how these two flags work on files within a file system.

As shown in below figure, system c103rp03.gpfs.net on AIX is one of the nodes of cluster karmic.gpfs.net on which GPFS 3.4v is installed. (For additional information on installation of GPFS on an AIX node, see Resources.)

Code 1: AIX server in use
(08:17:37) c103rp03 / $ hostname
c103rp03.gpfs.net

(08:17:40) c103rp03 / $ uname -a
AIX c103rp03 3 5 002405FB4C00

(08:17:45) c103rp03 / $ oslevel
5.3.0.0

To check the GPFS version present on AIX machine, run the command ‘lslpp -l gpfs*’

Code 2: GPFS version in use
(08:17:58) c103rp03 /gpfs/fs1 $ lslpp -l gpfs*
  Fileset                      Level  State      Description
  --------------------------------------------------------------------------------------
  Path: /usr/lib/objrepos
    gpfs.base                3.4.0.0  COMMITTED  GPFS File Manager
  Path: /usr/share/lib/objrepos
    gpfs.docs.data           3.4.0.0  COMMITTED  GPFS Server Manpages and  Documentation

GPFS has its own set of rich command line interfaces (CLIs) that allow AIX user to interact with the system. One of these commands is mmlscluster, which shows GPFS cluster configurations.

Code 3: Listing cluster configurations
(08:18:34) c103rp03 / $ mmlscluster
GPFS cluster information
========================
  GPFS cluster name:         karmic.gpfs.net
  GPFS cluster id:           13882456366448342595
  GPFS UID domain:           karmic.gpfs.net
  Remote shell command:      /usr/bin/rsh
  Remote file copy command:  /usr/bin/rcp

GPFS cluster configuration servers:
-----------------------------------
  Primary server:    c103rp04.gpfs.net
  Secondary server:  c103rp07.gpfs.net
  
 Node  Daemon node name          IP address       Admin node name        Designation
-----------------------------------------------------------------------------------------
   1   c103rp04.gpfs.net         192.168.100.132  c103rp04.gpfs.net
   2   c103rp05.gpfs.net         192.168.100.133  c103rp05.gpfs.net      quorum-manager
   3   c103rp06.gpfs.net         192.168.100.134  c103rp06.gpfs.net      quorum-manager
   4   c103rp07.gpfs.net         192.168.100.135  c103rp07.gpfs.net      manager
   5   c103rp08.gpfs.net         192.168.100.136  c103rp08.gpfs.net      manager
   6   c103rp09.gpfs.net         192.168.100.137  c103rp09.gpfs.net      quorum-manager
   8   c103rp10.gpfs.net         192.168.100.138  c103rp10.gpfs.net      quorum-manager
   9   c103rp03.gpfs.net        192.168.100.131  c103rp03.gpfs.net

The cluster karmic.gpfs.net has the GPFS file system 'fs1' mounted at point /gpfs/fs1, which is shared directory accessible from all the cluster nodes. The GPFS command mmcrfs is used to create a file system on the GPFS cluster. The mount point of the file system can be validated using the mmlsfs command.

Code 4: GPFS mount point
(08:19:06) c103rp03 / $ mmlsfs fs1 -T
flag                value                    description
------------------- ------------------------ -----------------------------------
 -T                 /gpfs/fs1                Default mount point

Let's create a file Test_File_1 from the AIX node ‘c103rp03.gpfs.net’ in the mounted directory /gpfs/fs1. GPFS command mmlsattar shows all the attributes of the file specified.

Code 5: Listing file attributes
(08:19:20) c103rp03 / $ cd /gpfs/fs1

(08:19:25) c103rp03 /gpfs/fs1 $ touch Test_File_1

(08:19:33) c103rp03 /gpfs/fs1 $ mmlsattr -L Test_File_1
file name:            Test_File_1
metadata replication: 1 max 2
data replication:     1 max 2
immutable:	      no
appendOnly:    	      no
flags:
storage pool name:    system
fileset name:         root
snapshot name:

Here, as we can see, there are two flags named immutable and appendOnly associated with Test_File_1. Currently, values for both the flags are 'no' as none of the flags is set.


Immutability restrictions in GPFS

GPFS has a specialized command called mmchattr, which is used to set or unset the immutable flag for files. After the file is set immutable, neither the file nor any of its parent directories can be renamed. A single path is provided to such files, which implies that hardlinks and fileset unlinks are not allowed for immutable files.

The mmchattr -i yes|no command sets or unsets a file to or from an immutable state.

Where -i yes sets the immutable attribute of the file to yes, and -i no sets the immutable attribute of the file to no.

To check whether the flag is set on the file, run the mmlsattr GPFS command.

Code 6: Setting and verifying immutable flag for a file
(08:19:52) c103rp03 /gpfs/fs1 $ mmchattr -i yes Test_File_1

(08:20:03) c103rp03 /gpfs/fs1 $ mmlsattr -L Test_File_1
file name:            Test_File_1
metadata replication: 1 max 2
data replication:     1 max 2
immutable:            yes
appendOnly:           no
flags:
storage pool name:    system
fileset name:         root
snapshot name:

File operations on immutable files

When a file is marked as immutable, the behavior of file operations changes accordingly.

  1. Delete: Immutable files can't be deleted.
    Code 7: Delete operation on the immutable file
    (08:20:13) c103rp03 /gpfs/fs1 $ rm -rf Test_File_1
    rm: Test_File_1 not removed.
    Read-only file system
  2. Modify/ Append:These files cannot be edited or appended. Any attempt made to edit or append an immutable file results in an error.
    Code 8: Modify/Append operation on the immutable file
    (08:20:24) c103rp03 /gpfs/fs1 $ echo "abc" > Test_File_1
    bash: Test_File_1: Read-only file system
    
    (08:20:51) c103rp03 /gpfs/fs1 $ echo "abc" >>  Test_File_1
    bash: Test_File_1: Read-only file system

    Note that the Immutable flag applied on a file takes effect only after the file is closed. So, if the file is open when you set the flag, you can still modify or append it.

  3. Changing ACLs: ACLs (read/write/execute permissions for owner/group/user) for immutable file cannot be changed or deleted.

    The GPFS mmgetaclcommand displays the current list of permissions for a file while mmdelacl is used to delete existing permissions of a file. After you set immutable flag for a file, it is impossible to delete or modify the access permissions.

    Code 9: Changing ACLs for the immutable file
    (09:30:32) c103rp03 /gpfs/fs1 $ mmgetacl Test_File_1	
    #owner:root
    #group:system
    user::rw-c
    group::r---
    other::r---
    
    (09:31:09) c103rp03 /gpfs/fs1 $ mmdelacl Test_File_1
    mmdelacl: Authorization failure
  4. Changing mode: One cannot change an immutable file's mode.
    Code 10: Changing the mode of the immutable file
    (08:21:04) c103rp03 /gpfs/fs1 $ chmod u+x Test_File_1
    chmod: Test_File_1: Not owner
  5. Immutable directories: After a directory is marked as immutable, no files can be created, deleted or renamed within that directory. However, subdirectories still remain mutable unless and until you mark them immutable explicitly.

    For example, in the following code snippet, a directory called Test_Dir with four files m1, m2, m3, m4 and a subdirectory sub_dir1 are created. Then, the immutable flag is set for directory Test_Dir using mmchattr command and its file attributes are listed using the mmlsattr command.

    Code 11: Setting the immutable flag for the directory
    (09:34:22) c103rp03 /gpfs/fs1 $ mkdir Test_Dir
    
    (09:34:29) c103rp03 /gpfs/fs1 $ cd Test_Dir
    
    (09:34:34) c103rp03 /gpfs/fs1/Test_Dir $ touch m1 m2 m3 m4
    
    (09:36:08) c103rp03 /gpfs/fs1/Test_Dir $ mkdir sub_dir1
    
    (09:36:10) c103rp03 /gpfs/fs1/Test_Dir $ ls
    m1        m2        m3        m4        sub_dir1
    
    (09:36:39) c103rp03 /gpfs/fs1/Test_Dir $ cd ..
    
    (09:36:43) c103rp03 /gpfs/fs1 $ mmchattr -i yes Test_Dir
    
    (09:36:56) c103rp03 /gpfs/fs1 $ mmlsattr -L  Test_Dir
    file name:            Test_Dir
    metadata replication: 1 max 2
    data replication:     1 max 2
    immutable:            yes
    appendOnly:           no
    flags:
    storage pool name:    system
    fileset name:         root
    snapshot name:

    Now, any attempt to delete, create and rename a file within the directory fails with an error prompt.

    Code 12: Delete/create/rename operation on the immutable directory
    (09:37:30) c103rp03 /gpfs/fs1 $ cd Test_Dir/
    
    (09:37:41) c103rp03 /gpfs/fs1/Test_Dir $ rm -rf m1
    rm: m1 not removed.
    Read-only file system
    
    (09:38:18) c103rp03 /gpfs/fs1/Test_Dir $ touch m5
    touch: m5 cannot create
    
    (09:38:29) c103rp03 /gpfs/fs1/Test_Dir $ mv m2 m5
    mv: cannot rename m2 to m5:
    Read-only file system

    However, subdirectory sub_dir1 is still mutable and allows operations such as creating a new file and renaming an existing file within it.

    File operations on subdirectories of the immutable directory
    (09:41:16) c103rp03 /gpfs/fs1/Test_Dir $ cd sub_dir1
    
    (09:41:18) c103rp03 /gpfs/fs1/Test_Dir/sub_dir1 $ touch s1 s2
    
    (09:41:27) c103rp03 /gpfs/fs1/Test_Dir/sub_dir1 $ ls
    s1  s2
    
    (09:41:29) c103rp03 /gpfs/fs1/Test_Dir/sub_dir1 $ mv s1 s3
    
    (09:41:51) c103rp03 /gpfs/fs1/Test_Dir/sub_dir1 $ ls
    s2  s3
  6. Time stamp: Time stamp of an immutable file can be changed.
    Code 14: Changing time stamp of the immutable file
    (09:32:47) c103rp03 /gpfs/fs1 $ ls -ltr Test_File_1
    -rw-r--r--    1 root     system            0 Nov  9 08:19 Test_File_1
    
    (09:33:43) c103rp03 /gpfs/fs1 $ touch Test_File_1
    
    (09:33:46) c103rp03 /gpfs/fs1 $ ls -ltr Test_File_1
    -rw-r--r--    1 root     system            0 Nov  9 09:33 Test_File_1

appendOnly restrictions in GPFS

In GPFS, you can set the appendOnly flag for a file using the same mmchattr command with -a yes|no option. Also, you can verify the appendOnly flag using the same GPFS command mmlsattr.

The mmchattr -a yes|no command sets or unsets a file to or from an appendOnly state. -a yes sets the immutable attribute of the file to yes and -a no sets the appendOnly attribute of the file to no.

Code 15: appendOnly flag for the file
(09:42:25) c103rp03 /gpfs/fs1 $ pwd
/gpfs/fs1

(09:42:28) c103rp03 /gpfs/fs1 $ touch Test_File_2

(09:42:47) c103rp03 /gpfs/fs1 $ mmchattr -a yes Test_File_2

(09:42:56) c103rp03 /gpfs/fs1 $ mmlsattr -L Test_File_2
file name:            Test_File_2
metadata replication: 1 max 2
data replication:     1 max 2
immutable:            no
appendOnly:           yes
flags:
storage pool name:    system
fileset name:         root
snapshot name:

File operations on appendOnly files

  1. Delete: appendOnly files cannot be deleted.
    Code 16: Delete operation on the appendOnly file
    (09:42:59) c103rp03 /gpfs/fs1 $ rm -rf Test_File_2
    rm: Test_File_2 not removed.
    Read-only file system
  2. Modify/Append: These files cannot be edited but can be appended.
    Code 17:Modify/Append operation on the appendOnly file
    (09:43:01) c103rp03 /gpfs/fs1 $ echo "abc" > Test_File_2
    bash: Test_File_2: Read-only file system
    
    (09:43:41) c103rp03 /gpfs/fs1 $ echo "abc" >> Test_File_2
    
    (09:43:42) c103rp03 /gpfs/fs1 $ cat Test_File_2
    abc
  3. Changing ACLs: ACLs (read/write/execute permissions for owner/group/user) for the appendOnly file can't be changed or deleted.
    Code 18: Changing ACLs of the AppendOnly file
    (09:44:04) c103rp03 /gpfs/fs1 $ mmgetacl Test_File_2
    #owner:root
    #group:system
    user::rw-c
    group::r---
    other::r---
    
    (09:44:15) c103rp03 /gpfs/fs1 $ mmdelacl Test_File_2
    mmdelacl: Authorization failure
  4. Changing mode: You cannot change the mode of a file for which the appendOnly mode is set.
    Code 19: Changing mode of the appendOnly file
    (09:43:47) c103rp03 /gpfs/fs1 $ chmod u+x Test_File_2
    chmod: Test_File_2: Not owner
  5. appendOnly directory: After a directory is marked as appendOnly, no files can be deleted or renamed within that directory.

    However, files of zero byte can be created. In the following example, Test_AppendOnly is a directory having files a1 a2 a3 and the subdirectory sub_dir1. Then, the appendOnly flag is set for directory Test_AppendOnly using the mmchattr command.

    Code 20: Setting the appendOnly flag for the directory
    (09:44:24) c103rp03 /gpfs/fs1 $ mkdir Test_AppendOnly
    
    (09:44:30) c103rp03 /gpfs/fs1 $ cd Test_AppendOnly
    
    (09:44:35) c103rp03 /gpfs/fs1/Test_AppendOnly $ touch a1 a2 a3
    
    (09:44:43) c103rp03 /gpfs/fs1/Test_AppendOnly $ mkdir sub_dir1
    
    (09:44:51) c103rp03 /gpfs/fs1/Test_AppendOnly $ ls
    a1        a2        a3        sub_dir1
    
    (09:44:58) c103rp03 /gpfs/fs1/Test_AppendOnly $ cd ..
    
    (09:45:09) c103rp03 /gpfs/fs1 $ mmchattr -a yes Test_AppendOnly
    
    (09:45:15) c103rp03 /gpfs/fs1 $ mmlsattr -L Test_AppendOnly
    file name:            Test_AppendOnly
    metadata replication: 1 max 2
    data replication:     1 max 2
    immutable:            no
    appendOnly:           yes
    flags:
    storage pool name:    system
    fileset name:         root
    snapshot name:

    Now, as you can see below, files within the directory Test_AppendOnly can't be deleted or renamed. However, new files can still be created in the same directory.

    Note that if you set both the immutable and appendOnly flag on a file or directory, immutable settings will take effect.


Industrial applications

Depending on the requirements of your business and nature of data to be protected, you can select the appropriate flag for your files. Also, sometimes files are mistakenly deleted by the owner due to some typo. Restrictions provided by these GPFS flags help avoid such common mistakes.

Organizations need to protect the business audit files, health center records of patients, log files and more in the file system from any damage and malicious data entry. In such cases, using the immutability and appendOnly features is the best practice to effectively secure your data.


Conclusion

In this article, we have discussed how the immutability and appendOnly features in GPFS 3.4v can be used to protect your confidential files on AIX systems from being tampered with. For additional information on these features on GPFS, please refer to the GPFS V3.4 Advanced Administration Guide (see Resources).

Acknowledgement

The authors sincerely acknowledge Bhushan Jain (bhujain1@in.ibm.com) from IBM Corporation for reviewing this article and providing his valuable suggestions.

Resources

Learn

Get products and technologies

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into AIX and Unix on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=AIX and UNIX, Java technology
ArticleID=811924
ArticleTitle=Immutability and appendOnly features in GPFS 3.4v on AIX
publish-date=04302012