26.9.10 Configuring File System Mounts, File Permissions, and File Ownerships

Use separate disk partitions for operating system and user data to prevent a file system full issue from impacting the operation of a server. For example, you might create separate partitions for /home, /tmp, p, /oracle, and so on.

Establish disk quotas to prevent a user from accidentally or intentionally filling up a file system and denying access to other users.

To prevent the operating system files and utilities from being altered during an attack, mount the /usr file system read-only. If you need to update any RPMs on the file system, use the -o remount,rw option with the mount command to remount /usr for both read and write access. After performing the update, use the -o remount,ro option to return the /usr file system to read-only mode.

To limit user access to non-root local file systems such as /tmp or removable storage partitions, specify the -o noexec, nosuid, nodev options to mount. These option prevent the execution of binaries (but not scripts), prevent the setuid bit from having any effect, and prevent the use of device files.

Use the find command to check for unowned files and directories on each file system, for example:

# find mount_point -mount -type f -nouser -o -nogroup -exec ls -l {} \;
# find mount_point -mount -type d -nouser -o -nogroup -exec ls -l {} \;

Unowned files and directories might be associated with a deleted user account, they might indicate an error with software installation or deleting, or they might a sign of an intrusion on the system. Correct the permissions and ownership of the files and directories that you find, or remove them. If possible, investigate and correct the problem that led to their creation.

Use the find command to check for world-writable directories on each file system, for example:

# find mount_point -mount -type d -perm /o+w -exec ls -l {} \;

Investigate any world-writable directory that is owned by a user other than a system user. The user can remove or change any file that other users write to the directory. Correct the permissions and ownership of the directories that you find, or remove them.

You can also use find to check for setuid and setgid executables.

# find path -type f \( -perm -4000 -o -perm -2000 \) -exec ls -l {} \;

If the setuid and setgid bits are set, an executable can perform a task that requires other rights, such as root privileges. However, buffer overrun attacks can exploit such executables to run unauthorized code with the rights of the exploited process.

If you want to stop a setuid and setgid executable from being used by non-root users, you can use the following commands to unset the setuid or setgid bit:

# chmod u-s file
# chmod g-s file

The following table lists programs for which you might want to consider unsetting the setuid and setgid:

Program File

Bit Set

Description of Usage



Finds out password aging information (via the -l option).



Changes finger information.



Changes the login shell.



Edits, lists, or removes a crontab file.



Sends a system-wide message.



Sends a message to another user.



Invokes the X Windows server.



Runs the SSH helper program for host-based authentication.



Mounts an NFS file system.


/sbin/mount.nfs4, /sbin/umount.nfs, and /sbin/umount.nfs4 are symbolic links to this file.



Requests notification of changes to network interfaces.



Controls network interfaces. Permission for a user to alter the state of a network interface also requires USERCTL=yes to be set in the interface file. You can also grant users and groups the privilege to run the ip command by creating a suitable entry in the /etc/sudoers file.


This list is not exhaustive as many optional packages contain setuid and setgid programs.