umask(0);
fd = open(\"/dev/null\", O_RDWR);
Here\'s man 2 umask
:
umask() sets the calling process’s file mode creatio
The umask is applied to all modes used in file system operations. From the manual open(2)
:
The permissions of the created file are
(mode & ~umask)
So with a single call to umask, you can influence the mode of all create files.
This is usually used when a program wants the user to allow to overrule the default grants for files/directories it creates. A paranoid user (or root) can set the umask to 0077
which means that even if you specify 0777
in open(2)
, only the current user will have access.
I know this is and old question but here is my two cents:
Permissions of shared memory object
I was trying to make a shared memory object, with:
int shm_open(const char *name, int oflag, mode_t mode);
The resulting shared memory did not have the permission set in mode argument, so I read the shm_open man page which led me to the open function man page and there it says:
mode specifies the permissions to use in case a new file is created. This argument must be supplied when O_CREAT is specified in flags; if O_CREAT is not specified, then mode is ignored. The effective permissions are modified by the process's umask in the usual way: The permissions of the created file are (mode & ~umask). Note that this mode only applies to future accesses of the newly created file
So I tried to modify the umask with:
mode_t umask(mode_t mask);
but it did not work either, so after more google I found this Setting Permission document in gnu.org
Which recommends:
When your program needs to create a file and bypass the umask for its access permissions, the easiest way to do this is to use fchmod after opening the file, rather than changing the umask. In fact, changing the umask is usually done only by shells. They use the umask function.
and with fchmod my function worked as I wanted :) her it is:
int open_signals_shmem(struct signal_shmem **shmem, int size)
{
int fd, ret;
void *ptr;
*shmem = NULL;
ret = 1;
fd = shm_open(SIGNALS_SHMEM_NAME, O_RDWR | O_CREAT, S_IRWXU | S_IRWXG | S_IRWXO);
if (fd == -1)
{
printf("error: signals shmem could not be allocated (%s, errno=%d)\n", SIGNALS_SHMEM_NAME, errno);
}
else
{
// Change permissions of shared memory, so every body can access it
fchmod(fd, S_IRWXU | S_IRWXG | S_IRWXO);
if (ftruncate(fd, size) == -1)
{
printf("error: signals shmem could not be truncated (%s, errno=%d)\n", SIGNALS_SHMEM_NAME, errno);
}
else
{
ptr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if (ptr == MAP_FAILED)
{
printf("error: signals shmem could not be mapped (%s, errno=%d)\n", SIGNALS_SHMEM_NAME, errno);
}
else
{
*shmem = ptr;
ret = 0;
}
}
}
return ret;
}
Citing this article:
The purpose of the umask is to allow users to influence the permissions given to newly created files and directories. Daemons should not allow themselves to be affected by this setting, because what was appropriate for the user will not necessarily be suitable for the daemon.
In some cases it may be more convenient for the umask to be set to a non-zero value. This is equally acceptable: the important point is that the daemon has taken control of the value, as opposed to merely accepting what it was given.
Most Mac developers (and by extension most software testers), from the time they were babies, put this in their .cshrc
umask 002
However, most end users don't know about umask, so if they create a new user on the machine, and run your app, you are likely to create a bunch of log files and whatnot without group read/write permissions. Then they switch users again and suddenly your app doesn't work. For this reason, we're adding this to all our apps. Our rule-of-thumb when it comes to security is that "we want users to be able to use our software".
#import <sys/types.h>
#import <sys/stat.h>
int main(int argc, char *argv[])
{
// set permissions for newly created files to ug+rwX,o+rX
umask(0002);