Getting grips with fpm

Tightening SUID programs

Using the File Permissions Manager (fpm) allows you to trim down the programs that should not be SUID or SGID enabled in your view. Thus, allowing only privileged users to run these programs. This use of fpm is part of the ever-growing IBM® AIX® security policy to help system administrators in hardening their system.


David Tansley (, UNIX administrator, Freelance Writer

David Tansley is a freelance writer. He has 15 years experience as a UNIX administrator, using AIX the last eight years. He enjoys playing badminton then relaxing watching Formula 1, but nothing beats riding and touring on his GSA motorbike with his wife.

07 August 2012

Also available in Chinese Russian

Understand SUID

SUID or SGID are permission bits that can be set on a program to allow unprivileged users to run the program as the owner of that program, generally but not always for the duration of its execution. Looking at the password command (owned by root), as an example:

$ ls -l passwd
-r-s r-x r-x   1 root security   29122 Aug 8 00:16 passwd

If I want to change my password, I would run the previous command. This enables me to change my password and write the encrypted password to the /etc/security/passwd file (other processes happen here, but they are not be discussed here). As an ordinary user, I would not be allowed to update the /etc/security/passwd file. However, as the passwd program is SUID and owned by root, the file is updated as the user root and not on my ID. In a nutshell, an unprivileged user can run a SUID set program as the owner.

AIX reports on two types of user IDs. They are:

  • The real user ID
  • The effective (privileged) user ID

The effective ID is the ID that owns the program or file. So, in the password example, if user dxtans runs the passwd command:

  • The real user ID would be dxtans
  • The effective user ID would be root

To determine the user ID information (that is, the real and effective user ID , which will be the same in all cases), and if the id command is run from the command line. then only the real ID will be shown. The real user ID is the user that starts a process.

$ whoami
$ id
uid=204(dxtans) gid=1(staff) groups=201(admin),208(sysmaint)

To make a compiled program SUID or SGID use the chmod command, using octal notation, the first octet is used, where:

  • 4 is for SUID
  • 2 is for SGID

For example, to make the following examples available for read and run for everyone, then:

chmod 4555 <file-name> makes the file SUID:

r-s r-x r-x

chmod 6555 <file-name> makes the file, both SUID and SGID:

r-s r-s r-x

To take the SUID off, using the first example, run the following command:

chmod 555 < file-name>

If the id command is ran from within a SUID wrapper program, which is owned by root and ran by another (unprivileged) user, it displays both, the real and effective ID. The following C code calls the id command. We can see both the IDs displayed as long as the program is SUID.

# cat idshow.c
int main(void)



As user root, create the previous file and name it idshow.c, and then compile it.

# gcc -o idshow idshow.c

Next, set the SUID bit on the file.

# chmod 4555 idshow
# ls -l
-r-s r-x r-x 1 root system   52699 Nov 28 10:07 idshow

Now as a different user, (in this example, dxtans), issue the id command:

$ id
uid=204(dxtans) gid=1(staff) groups=201(admin),208(sysmaint)

Now, run the newly created program as that different user:

$ ./idshow
uid=204(dxtans) gid=1(staff) euid=0(root) groups=201(admin),208(sysmaint)

In the output from the id command (called from idshow), notice that the ID of the user is dxtans. However, a new field named euid has been created, which is the effective user ID of the user in the previous program, and in this case, it is root.

 Setting the SGID bit on directories that holds logs or documents, you can allow 
different group members to write to one directory, thus allowing the system administrator 
not having to go down the path of doing a chmod 777.

Review SUID usage with care

When I refer to the SUIDs, I also include the SGIDs in that reference, throughout the rest of this article. Generally speaking, some SUID programs are considered as a potential security risk. They are ran as the effective user ID, and in the most common cases, this would be user root. Thus root is open to all users on these SUID set programs. Though now ignored by the kernal, shell scripts that had careless write permissions on SUID shell scripts was a nightmare, as it can totally open your system in the wrong hands. These are just some of the reasons why AIX and most other UNIX® and Lunix® systems ignore any shell scripts that have their SUID or SGID bits set due to this very real security issue. It is a common practice nowadays to disable or rather remove some of the SUID systems or application commands, and instead use sudo or role-based authority to run these programs by unprivileged users. This is certainly the case when adhering to security policies and you are required to restrict the root access. This does mean re-evaluating some of the root-based SUID commands. AIX has acknowledged this and has provided a utility named fpm that removes the SUID bits from programs. The fpm utility controls the amount of SUID and SGID programs you want to set or remove. Though fpm is part of the AIX security Role Based Access Control (RBAC) and aixpert implementation for AIX 6, fpm is also included in the 5.3 TL6 release onwards. Though the usage of the SUID programs should be reviewed, note that there are quite a few SUID programs, similar to the passwd command, that should be left alone.

To locate all the SUID and SGID programs in your server, use the following find command:
# find / -perm -4000 -o -perm

Here comes fpm

The fpm utility allows you to restrict the execution of the SUID programs by removing the corresponding SUID bits. AIX offers the following security levels based on the general security policy and the best guessed usage by unprivileged users.

  • High level
  • Medium level
  • Low level
  • Additional custom level

The locations of the files that fpm uses are:

  • /usr/lib/security/fpm/data

    holds the files that contain system SUIDs for the different levels

  • /usr/lib/security/fpm/custom

    holds custom files that contains bespoke SUIDs

Within the directory /usr/lib/security/fpm/data you have the following lists, containing the files that will be changed:

  • High uses the high_fpm list and will remove all SUID/SGID contained in that list
  • Medium uses the med_fpm list and remove all SUID/SGID contained in that list.
  • Low used the med_fpm list and remove all SUID contained in that list.
  • The default level will use the default_list_example and restore all SUID/SGID in that list to an

    AIX default installation.

Within the /usr/lib/security/fpm/custom directory, you have the following subdirectories that can hold the custom list depending on the security level ran, where the SUID will have bits removed or added:

  • Default
  • High
  • Medium

The most common usage of the fpm command is:

fpm -l <level>  -p -v -f


  • level is either high, medium, low, or default
  • -p is to preview the results only, there is no actual change to files
  • -v be verbose in its output, by default there is minimal output when ran without preview
  • -f is a file containing the file names to be changed

The custom directory holds your bespoke/custom SUID files that you want to process.

The data directory holds the different levels as determined by IBM AIX, the file names are self explanatory. You should review the contents of these files to see what programs get changed. You need to be aware of the implications of certain SUID bits being removed from files.

Any changes made by fpm are logged into a log file held in: /var/security/fpm/log.

When fpm is ran, depending on the level parsed, it will also include the file contents, if present in the corresponding custom directory. So, if I need to run fpm at a medium level, it would use the list contained in: /usr/lib/security/fpm/data/med_fpm_list and also the list (if present) contained in: /usr/lib/security/fpm/custom/medium.

As a precautionary measure, when I first ran fpm, I made sure that I had a system backup. However fpm ran as advertised, without any problem.

If fpm is ran and the resulting changes then have a negative impact on the system, you can revert back to your previous settings or revert back to the original setting that came when the server was installed with AIX.

Changing the SUID permissions

Before running fpm, decide on the level you want to implement. For example, if you want to implement the medium level, you first need to preview the files that that would be affected with the SUID changes contained in: /usr/lib/security/fpm/data/med_fpm_list.

Then run a preview of fpm as if the medium policy was implemented, as follows

# fpm -l medium -p
chmod 0555 /sbin/helpers/jfs2/backbyinode
chmod 0550 /sbin/helpers/jfs2/diskusg
chmod 0555 /sbin/helpers/jfs2/restbyinode

The output indicates the newly changed permissions of the files. That is, which files have had the SUID bits removed and the resulting new permissions. As this is ran in the preview mode, no changes will occur. After you are satisfied with the files that will have their SUID bits removed, you can then progress onward and actually remove then:

# fpm -l medium

One or more file is already secure. Therefore, the current file permissions may not match the default permissions. If you need to return to the snapshot of permissions prior to running this command, then run the command: /usr/bin/fpm -l default -f /var/security/fpm/log/12062011_17:48:35 fpm will now continue to remove the SUID permissions.

If you want verbose output, that is, output that is similar to running it with the preview option, then use the v parameter.

The files will now be removed of their SUID bits for real. In the fpm output, notice the command to use to revert back any changes you made. The original settings are held in an output file, as displayed in the above example.

Next, check that some of the files have actually had their SUID bits removed.

# ls -l /usr/sbin/chdev
-r-xr-x---    1 root     system        27496 Mar 22 2011  /usr/sbin/chdev

Finally, to confirm that you are at the medium level as actioned by fpm, run the following command.

# fpm -s
Medium level security.

The next task is to test and retest to make sure that your applications and operating environment has not been impacted by the SUID changes.

Reverting back

If you decide that the medium level is not for you after you have implemented the medium security changes, simply revert the file permissions back. The log files are held in: /var/security/fpm/log.

The format of the log file contents is:

<suid octal permission to restore> < full path/file-name> <current octal permission>

A sample output of the log file is shown for your reference.

# cat 12062011_17:48:35
4550 /usr/sbin/cfgmgr 0550
4550 /usr/sbin/chcod 0550
4550 /usr/sbin/chcons 0550
4550 /usr/sbin/chdev 0550

Using the log file generated from the previous medium security change, we can now restore back to the point prior to this. Using the log file that was generated from the previous medium security change, use the -f option and specify the security level as default:

 # fpm -l default  -f /var/security/fpm/log/12062011_17:48:35

Next, confirm that the change has happened by looking at a restored permissions file.

# ls -l /usr/sbin/chdev
-r-sr-x---    1 root     system        27496 Mar 22 2011  /usr/sbin/chdev

Next, view the status of the security level. It will state customised, as the SUID list has been restored from your backup taken previously.

# fpm -s
Customized level security.

TThough AIX has provided a list specifying the files that need to be included for different security settings, you can further modify this to exclude or include certain files. I excluded quite a few of the SUID programs held in the medium security file, /usr/lib/security/fpm/data/med_fpm_list, and used this as my standard setup. This works well for me as a system administrator.

To restore SUID to the factory default, (that is the SUID setting as if AIX was just installed), use the following command:

# fpm -l default

Then, confirm the status of the new security level.

# fpm -s
Default level security.

Customize the SUID changes

To add customized files to a list, that is, to include application and other system SUIDs, you have a couple of choices here.

  • Create a list containing the names of the file whose SUIDs are to be removed.
  • Create a list containing the names of the files whose SUIDs are to be restored.

In the /usr/lib/security/fpm directory, there is a subdirectory called custom, and within that subdirectory there are the following directories: default, medium, and high.

IIf you need to revert back to the original SUID program setting, you can include additional files as well, these would probably include your bespoke or application SUIDs. The format for the file is:

<suid octal permission to restore> < full path/file-name>

For example, run the following commands to include two custom SUIDs, called grab_db2_audit and load_extract, in the file named mydefaults.

# pwd

# cat mydefaults
4550 /usr/local/bin/grab_db2_audit
4550 /usr/local/bin/load_extract

The customized process I am demonstrating in this section applies to the other levels as well.

If you restore to the default level, any file in this directory (assuming that it is in the correct format) will be included when the permissions are changed on the SUIDs.

 # fpm -l default
chmod 4550 /usr/sbin/invscoutd
chmod 4550 /usr/local/bin/grab_db2_audit
chmod 4550 /usr/local/bin/load_extract

To remove the SUID bits on the custom SUIDs or any additional files, create a file with a list of those files for which you need to remove their SUID bits. The format of the file contents is:

< full path /file-name>

For example in my file called: mydefaults2, I can have:

# pwd

# cat  mydefaults2

The two SUID files are located in the /usr/local/bin directory prior to fpm removing the SUIDs:

# pwd

# ls -lt |head
total 9512
-r-sr-x---    1 root     app1          30681 Dec 05 22:17 load_extract
-r-sr-x---    1 aixdev   app1          52697 Dec 05 18:08 grab_db2_audit

Next, run fpm to change the security level to medium. Then confirm the status of the security level after running fpm. Then check whether the custom files have been removed of their SUID bits.

# fpm -l medium

# fpm -s
Medium level security.
# ls -lt |head
total 9512
-r-xr-x---    1 root     app1          30681 Dec 05 22:17 load_extract
-r-xr-x---    1 aixdev   app1          52697 Dec 05 18:08 grab_db2_audit

Watch out for ACLs

One thing to watch out for is that running fpm over an access control list (ACL) file will disable that ACL file. Though the ACL attributes will remain intact, this is because a chmod in octal is carried out on the file in question which resets the ACL-enabled attribute. Looking at an ACL file called load_extract, before fpm is ran:

# aclget load_extract
* ACL_type   AIXC
attributes: SUID
base permissions
    owner(root):  r-x
    group(app1):  r-x
    others:  ---
extended permissions
    deny     r-x     u:alpha

We can see that the file is SUID and ACL enabled, and that user alpha is denied permission to run. Further, to confirm that the file is actually ACL, note the + sign at the end of the following permissions attributes:

# ls -lUt |head
total 9512
-r-sr-x---+    1 root     app1          30681 Dec 05 22:17 load_extract

If we were to run fpm and it included the load_extract file, ACL would be disabled.

#  fpm -l medium
# fpm -s
Medium level security.

# ls -lUt |head
-r-xr-x---    1 root     app1          30681 Dec 05 22:17 load_extract

In the listing, note that the + sign is no longer present. fpm has reset the ACL-enabled attribute. We can confirm that by issuing the aclget command on the file.

# aclget load_extract
* ACL_type   AIXC
base permissions
    owner(root):  r-x
    group(app1):  r-x
    others:  ---
extended permissions
    deny     r-x     u:alpha

Ensure to make a note of your ACLs and use the acledit command to re-enable them.


In my opinion, using fpm is a good procedure to use. It goes some way to further strengthen your security policy. However, the defaults files may not suit all. You need not hesitate to tailor one of the defaults sets to your own system security requirements.



Get products and technologies

  • Try out IBM software for free. Download a trial version, log into an online trial, work with a product in a sandbox environment, or access it through the cloud. Choose from over 100 IBM product trials.



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

Zone=AIX and UNIX
ArticleTitle=Getting grips with fpm