Linux file systems are an essential operating system resource. Modern file systems and disk drive technology are robust and reliable — so, most administrators put little effort into planning or worrying about them once the operating system is configured.
This makes me both smile and cringe.
I smile because the advancements in technology facilitate out-of-the-box reliability and performance for common installations regardless of the system administrator's skills.
The implementation allows applications which utilize them to be reliable and require little day-to-day maintenance.
I cringe because when it comes time for a system administrator to do proper planning and implementation of a very large or unique solution with a finite set of resources, many administrators lack the skills.
Storage Area Networks (SAN), advanced server hardware, and virtualization have provided a seemingly unlimited pool of resources.
When it comes to file systems, there are several different types. For the purposes of this blog post, I will focus on disk file systems which include ext3 and ext4.
However, there are other types such as special and network-based file systems.
I'd like to offer some thoughts on file system planning and implementation. They're intended to get you thinking about some important aspects of using file systems.
PLANNING — The Layout and Creation of File Systems
Defining a file system layout involves considering the use of each file system in the operating system. Most system administrators will simply choose the default which assigns the entire disk partition as one, big monolithic file system (/).
Consider creating separate file systems for data which is constantly growing and shrinking such as /tmp, /var/log, and /var/audit.
If you are going to have a large number of Linux user accounts, consider a separate file system such as /home — this will isolate non-privileged users which could potentially fill up the root file system (/).
Intentionally filling up a file system to degrade or halt a system is a form of denial of service. So, it is best to have a strategy which isolates critical file systems.
Next, think about the size and amount of data to be stored on the file system. For example, if the file system will be dedicated to a database you may have fewer files but can be very large.
If the file system will be comprised of many smaller files, then consider adjusting the inodes-per-bytes ratio. I've seen systems where the "df -h" command reports plenty of space however, the "df -ih" command reports no more space for inodes. If your file system needs change, some parameters can be adjusted later with tune2fs(8) command.
IMPLEMENTATION — Mounting File Systems
Once the file system is created, it is "mounted" to make it available to the operating system. Typically, file systems are mounted using its options specified in the /etc/fstab. Again, the majority of default mount options suffice for most environments.
Consider file systems which may be used for user home directories. You may want to prevent these users from executing binaries they've copied into their home directories — use the 'noexec' and 'nosuid' mount options on their file system to prevent this.
Another useful location for the 'noexec' and 'nosuid' options would be a file system dedicated to logging.
File systems dedicated to serving static content such as web pages and images are great candidates for the 'noexec' and 'nosuid' options as well. If the pages are seldom updated, consider mounting the file system as read-only using the 'ro' option.
By default, file systems such as ext2 and newer support POSIX.1e Access Control Lists (ACL). These ACLs provide fine-grained access control beyond the base user-group-other permissions.
However, many novice administrators do not understand the technology so excessive permissions could be hidden from them. If you are not comfortable or well-versed in POSIX ACLs, I recommend mounting file systems with the 'noacl' option to disable support for them.
Some security professionals might disagree with me but in my opinion a misuse of such technology could be very dangerous.
Cross-posted from Security Blanket Technical Blog
