1

I need to set default file creation permissions for everyone to 777 [rwx], however umask uses 666 for files:

  • If I need permissions to be 444, I would issue umask 222 [666 - 222 = 444], but the problem is I need to set them to 777

How do I achieve this?

JW0914
  • 7,052
  • 7
  • 27
  • 48
vikram singh
  • 29
  • 3
  • @harrymc: While the question is _very_ similar (and I was about to suggest setfacl myself), OP is asking how to make _files_ executable by default and that is not something that default ACLs would achieve, at least not in any way I tried -- the '+x' from default ACLs is always ignored when propagating them to files. – u1686_grawity Feb 14 '21 at 12:10
  • @user1686: Executable by default exists only on Windows. The most that is possible to do is in the [link](https://superuser.com/questions/808345/change-default-permissions-for-new-files-and-folders) I gave as duplicate. This is an unsolvable post, probably an X-Y problem, so any answer will do. – harrymc Feb 14 '21 at 13:29
  • A convoluted solution may be to use a `cron` job to monitor a directory every `1` min for new files, then use `find` to list files only, piping to `xargs` to change permissions [`find . -type f -name '*' | xargs chmod 777`]. As @harrymc mentioned, Windows is the only OS that requires execute permissions to open files, so if this is for a Windows share, use Samba and specify in the `smb.conf` `create mask = 0777` – JW0914 Feb 14 '21 at 14:31
  • 1
    @JW0914: Windows doesn't require +x to open files, it requires +x to _execute_ files -- in other words, +x on a file has the same meaning on both Windows and Linux. – u1686_grawity Feb 14 '21 at 15:29
  • @user1686 Ah, I mistyped and meant to say _modify_ not _open_. Execute permission doesn't mean the same thing in Windows and Linux - to modify a file in Windows that resides in Linux w/ UGO permissions, execute is a required permission, whereas in Unix-based OSes, write is all that's required. This can be seen in Advanced Security dialogue for a file in Windows, as once `Traverse folder / execute file` is removed, so is `Modify`, and is why at least `700` is required when modifying files in a Linux Samba share from Windows _(at least in Samba v3, as OpenWrt's v4 port isn't stable quite yet)_ – JW0914 Feb 14 '21 at 15:54
  • @JW0914: That is not true. The "Permissions" dialog only works this way because "Modify" is a combination of both "Read & Execute" plus "Write" -- but that doesn't mean that "Execute" is part of "Write". In practice, you can still change files even if you lack the Execute permission on them. – u1686_grawity Feb 14 '21 at 17:28
  • @JW0914: The only real difference between Windows and Unix-likes is that on Windows all users get a process-level privilege which bypasses "Traverse folder", so they can still access items within folders which they don't have +x for. (But this doesn't extend to files -- even on Windows you cannot execute an .exe file if you don't have +x for it, even if you have all other permissions.) – u1686_grawity Feb 14 '21 at 17:31
  • Thanks for the help guys . So , does that mean by default in linux the maximum permission for a file on its creation is 666 ? and also I cannot make file permission to executable on its creation in linux ? – vikram singh Feb 15 '21 at 10:40

1 Answers1

2

You really can't - there is no "default file permission" on POSIX systems.

File permissions are set when the file is created with either the open()/openat() or creat() function.

Per the open() specifications (note the bolded part, added to emphasize where file permission bits come from):

O_CREAT

If the file exists, this flag has no effect except as noted under O_EXCL below. Otherwise, if O_DIRECTORY is not set the file shall be created as a regular file; the user ID of the file shall be set to the effective user ID of the process; the group ID of the file shall be set to the group ID of the file's parent directory or to the effective group ID of the process; and the access permission bits (see <sys/stat.h>) of the file mode shall be set to the value of the argument following the oflag argument taken as type mode_t modified as follows: a bitwise AND is performed on the file-mode bits and the corresponding bits in the complement of the process' file mode creation mask. ...

The application creating the file picks the file's initial permissions, but with the bits that are non-zero in the process umask setting set to zero.

There is no "default" permission setting.

Andrew Henle
  • 220
  • 1
  • 7
  • This depends on the context - for example, Samba can be configured to apply default permissions on created files and/or directories in a share within the `smb.conf` – JW0914 Feb 14 '21 at 13:56
  • 1
    @JW0914 That just means Samba is setting permissions how it wants to, and likely explicitly calling [`[f]chmod()`](https://pubs.opengroup.org/onlinepubs/9699919799/functions/chmod.html) **after** file creation to ensure permissions are set per the Samba application's settings. The operating system is not not providing those default settings. – Andrew Henle Feb 14 '21 at 14:01
  • Would a convoluted solution then be to use a `cron` job to monitor a directory every `1` min for new files, then use `find` to list files only, piping to `xargs` to change permissions? [`find . -type f -name '*' | xargs chmod 777`] – JW0914 Feb 14 '21 at 14:16