Setting group/other write flags not honoured in open

[Marcelo Diop-Gonzalez]

Hey, I think this is because the process's umask is changing the mode. In
fs/namei.c in the function lookup_open() there's this bit:

....
if (!IS_POSIXACL(dir->d_inode))
  mode &= ~current_umask();
....

the open(2) and umask(2) manpages will explain how to deal with it

-Marcelo



On Sat, Oct 31, 2020 at 11:06 AM Nicky Chorley <ndchorley at gmail.com> wrote:

> Hi folks,
>
> I hope it's OK to ask this question here. I'm reading The Linux
> Programming Interface and am beginning to get to grips with the file
> oriented system calls.
>
> I have a program that calls open to create a file, specifying the mode
> flags for owner, group, other read and write. The file is created
> sucessfully, but when I look at its permissions, I only see the read
> perms set for group and others:
>
> > ./create_file foo
> > ls -l foo
> -rw-r--r-- 1 nick users 0 Oct 31 14:52 foo
>
> Why would that be? The entirety of my program is
>
> #include <fcntl.h>
> #include <unistd.h>
>
> int main(int argc, char *argv[]) {
>   int open_flags = O_CREAT | O_WRONLY | O_TRUNC;
>   mode_t file_perms =
>     S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH;
>
>   int output_fd = open(argv[1], open_flags, file_perms);
>
>   close(output_fd);
> }
>
> I also ran the program with strace and the perms in the openat call are
> as I would expect:
>
> openat(AT_FDCWD, "foo", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
>
> I don't understand why the group and other write flags aren't being
> set. Could someone help shed some light on this please?
>
> I'm not sure what factors influence this, but I'm running openSUSE Leap
> 15.2, with kernel 5.3.18-lp152.47-default, gcc 7.5.0 and glibc 2.26.
>
> Thanks,
>
> Nicky
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20201031/0a32c311/attachment.html>