GitHub
CERT Secure Coding

FIO06-C. Create files with appropriate access permissions

Creating a file with insufficiently restrictive access permissions may allow an unprivileged user to access that file. Although access permissions are heavily dependent on the file system, many file-creation functions provide mechanisms to set (or at least influence) access permissions. When these functions are used to create files, appropriate access permissions should be specified to prevent unintended access.

When setting access permissions, it is important to make sure that an attacker cannot alter them. (See FIO15-C. Ensure that file operations are performed in a secure directory .)

Noncompliant Code Example ( fopen() )

The fopen() function does not allow the programmer to explicitly specify file access permissions. In this noncompliant code example, if the call to fopen() creates a new file, the access permissions are implementation-defined :

Non-compliant code
char *file_name;
FILE *fp;

/* Initialize file_name */

fp = fopen(file_name, "w");
if (!fp){
  /* Handle error */
}

Implementation Details

On POSIX-compliant systems, the permissions may be restricted by the value of the POSIX umask() function [ IEEE Std 1003.1:2013 ].

The operating system modifies the access permissions by computing the intersection of the inverse of the umask and the permissions requested by the process [ Viega 2003 ]. For example, if the variable requested_permissions contained the permissions passed to the operating system to create a new file, the variable actual_permissions would be the actual permissions that the operating system would use to create the file:

requested_permissions = 0666;
actual_permissions = requested_permissions & ~umask();

For OpenBSD and Linux operating systems, any file created will have mode S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH (0666), as modified by the process's umask value. (See fopen(3) in the OpenBSD Manual Pages [ OpenBSD ].)

Noncompliant Code Example ( open() , POSIX)

Using the POSIX open() function to create a file but failing to provide access permissions for that file may cause the file to be created with overly permissive access permissions. This omission has been known to lead to vulnerabilities —for example, CVE-2006-1174 .

Non-compliant code
char *file_name;
int fd;

/* Initialize file_name */

fd = open(file_name, O_CREAT | O_WRONLY);
/* Access permissions were missing */

if (fd == -1){
  /* Handle error */
}

This example also violates EXP37-C. Call functions with the correct number and type of arguments .

Compliant Solution ( open() , POSIX)

Access permissions for the newly created file should be specified in the third argument to open() . Again, the permissions are modified by the value of umask() .

Compliant code
char *file_name;
int file_access_permissions;

/* Initialize file_name and file_access_permissions */

int fd = open(
  file_name,
  O_CREAT | O_WRONLY,
  file_access_permissions
);
if (fd == -1){
  /* Handle error */
}

John Viega and Matt Messier also provide the following advice [ Viega 2003 ]:

Do not rely on setting the umask to a "secure" value once at the beginning of the program and then calling all file or directory creation functions with overly permissive file modes. Explicitly set the mode of the file at the point of creation. There are two reasons to do this. First, it makes the code clear; your intent concerning permissions is obvious. Second, if an attacker managed to somehow reset the umask between your adjustment of the umask and any of your file creation calls, you could potentially create sensitive files with wide-open permissions.

Risk Assessment

Creating files with weak access permissions may allow unintended access to those files.

Recommendation Severity Likelihood Detectable Repairable Priority Level
FIO06-C Medium Probable No No P4 L3

Automated Detection

Tool

Version

Checker

Description

CodeSonar
9.1p0

BADFUNC.CREATEFILE

(customization)

Use of CreateFile

CodeSonar's custom checking infrastructure allows users to implement checks such as the following.

  • A check for all uses of fopen() .
  • A check for calls to open() with only two arguments.
  • A check for calls to open() where the third argument does not satisfy some specified requirement.
Helix QAC

2025.2

C5013
LDRA tool suite
9.7.1
44 SEnhanced Enforcement
Polyspace Bug Finder

R2025b

CERT C: Rec. FIO06-CChecks for file opened without setting access permissions.

Search for vulnerabilities resulting from the violation of this rule on the CERT website .

SEI CERT C++ Coding StandardVOID FIO06-CPP. Create files with appropriate access permissions
CERT Oracle Secure Coding Standard for JavaFIO01-J. Create files with appropriate access permissions
ISO/IEC TR 24772:2013Missing or Inconsistent Access Control [XZN]
MITRE CWECWE-276 , Insecure default permissions
CWE-279 , Insecure execution-assigned permissions
CWE-732 , Incorrect permission assignment for critical resource

Bibliography

[ CVE ]
[ Dowd 2006 ]Chapter 9, "UNIX 1: Privileges and Files"
[ IEEE Std 1003.1:2013 ]XSH, System Interfaces, open
XSH, System Interfaces, umask
[ ISO/IEC 9899:2011 ]Subclause K.3.5.2.1, "The fopen_s Function"
[ OpenBSD ]
[ Viega 2003 ]Section 2.7, "Restricting Access Permissions for New Files on UNIX"