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 220.127.116.11
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 18.104.22.168 COMMITTED GPFS File Manager Path: /usr/share/lib/objrepos gpfs.docs.data 22.214.171.124 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.
- 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
- 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.
- Changing ACLs: ACLs (read/write/execute permissions for owner/group/user) for immutable file cannot be changed or deleted.
mmgetaclcommand displays the current list of permissions for a file while
mmdelaclis 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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.
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.
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).
The authors sincerely acknowledge Bhushan Jain (email@example.com) from IBM Corporation for reviewing this article and providing his valuable suggestions.
- Get to know IBM General Parallel File System well. Learn, discover and share information on the IBM GPFS via it’s a wiki, forum and community.
- GPFS V3.4 Advanced Administration Guide
- Immutability on ext2/ext3 filesystems shows how the immutability feature works on ext2/ext3 file systems.
- Long term Preservation of Digital Information - an education presentation from SNIA.
- Learn more about HIPAA compliance.
- GPFS Installation on AIX nodes is a complete guide for the installation process.
- AIX and UNIX : Want more? The developerWorks AIX and UNIX zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials.
- developerWorks technical events and webcasts: Stay current with developerWorks technical events and webcasts.
Get products and technologies
- • AIX Expansion Pack and Web Download Pack: Start downloading now.
- AIX Toolbox for Linux Applications.
Dig deeper into AIX and Unix on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.