Page History

...

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

/* ... */
FILE * fptr = fopen(file_name, "w");
if (!fptr){
  /* Handle Error */
}
/* ... */

Implementation Details

On POSIX-compliant systems, the permissions may be restricted by the value of the POSIX {{umask()}} function \[[Open Group 04|AA. C References#Open Group 04]\].

...

The 'u' character can be thought of as standing for "umask," meaning that these are the same permissions that the file would have been created with by fopen().

/* ... */
FILE *fptr;
errno_t res = fopen_s(&fptr, file_name, "w");
if (res != 0) {
  /* Handle Error */
}
/* ... */

Non-Compliant Code Example: open() (POSIX)

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

/* ... */
int fd = open(file_name, O_CREAT | O_WRONLY); /* access permissions are missing */
if (fd == -1){
  /* Handle Error */
}
/* ... */

Compliant Solution: open() (POSIX)

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

/* ... */
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 03|AA. C References#Viega 03]\]:

...