Folder b and c are owned by user b and c.
A file created by a user will belong to that user.
You can use the user permission for b and c, and the group permissions for a.
If you set the SGID bit (g+s) on a folder, created files will get the group permission of that folder.
mkdir a
chown a:a a
chmod g+s a
mkdir b
chown b:a b
mkdir c
chown c:a c
(assuming all users are in a group of the same name.)
setguid
There are 2 forces here at work. The first is the setgid bit that's enabled on the folder, folder
.
drwxr-s---. user group folder
That's the s
in the pack of characters at the beginning of this line. They're grouped thusly:
d - directory
rwx - read/write/execute bits for user
r-s - read/execute/setuid bits for group
--- - nothing for other users
The r-s
means that any files or directories created inside this folder will have the group automatically set to the group group
.
That's what caused the files foo.txt
and bar.txt
to be created like so:
-rw-r--r--. user group foo.txt
-rw-rw-r--. user group bar.txt
permissions & umask
The permissions you're seeing are another matter. These are governed by the settings for your umask
. You can see what your umask
is set to with the command umask
:
$ umask
0002
NOTE: these bits are also called "mode" bits.
It's a mask so it will disable any of the bits related to permissions which are enabled. In this example the only bit I want off is the write permissions for other.
0 - skipping for this conversation
0 - value of user bits
0 - value of group bits
2 - value of other bits
The representation of the "bits" in this command are in decimal form. So a 2 equates to 010 in binary form, which is the write bit. A 4 (100) would mean you want read disabled. A 7 (111) means you want read/write/execute all disabled. Building it up from here:
$ umask 007
Would disable the read/write/execute bits for other users.
So then what about your files?
Well the umask
governs the permissions that will get set when a new file is created. So if we had the following umask
set:
$ umask 007
And started touching new files, we'd see them created like so:
$ touch newfile1.txt newfile2.txt
$ ls -l |grep newfile
-rw-rw---- 1 saml saml 0 Nov 3 22:34 newfile1.txt
-rw-rw---- 1 saml saml 0 Nov 3 22:34 newfile2.txt
If we changed it to something else, say this:
$ umask 037
$ ls -l |grep newfile
-rw-rw---- 1 saml saml 0 Nov 3 22:36 newfile1.txt
-rw-rw---- 1 saml saml 0 Nov 3 22:36 newfile2.txt
-rw-r----- 1 saml saml 0 Nov 3 22:35 newfile3.txt
-rw-r----- 1 saml saml 0 Nov 3 22:35 newfile4.txt
It won't have any impact on files that we've already created though. See here:
$ umask
0037
$ touch newfile1.txt newfile2.txt
$ ls -l | grep newfile
-rw-rw---- 1 saml saml 0 Nov 3 22:37 newfile1.txt
-rw-rw---- 1 saml saml 0 Nov 3 22:37 newfile2.txt
-rw-r----- 1 saml saml 0 Nov 3 22:35 newfile3.txt
-rw-r----- 1 saml saml 0 Nov 3 22:35 newfile4.txt
So then what's going on with the file browser?
The umask
is what I'd called a "soft" setting. It is by no means absolute and can be by-passed fairly easily in Unix in a number of ways. Many of the tools take switches which allow you to specify the permissions as part of their operation.
Take mkdir
for example:
$ umask
0037
$ mkdir -m 777 somedir1
$
$ ls -ld somedir1
drwxrwxrwx 2 saml saml 4096 Nov 3 22:44 somedir1
With the -m
switch we can override umask
. The touch
command doesn't have this facility so you have to get creative. See this U&L Q&A titled: Can files be created with permissions set on the command line? for just such methods.
Other ways? Just override umask
. The file browser is most likely either doing this or just completely ignoring the umask
and laying down the file using whatever permissions it's configured to do as.
Best Answer
Yes, you can do that changing the
umask
. Theumask
determines which are the default permissions for a newly creted file.You can add
umask g+w
at the end of your shell configuration file (~/.bashrc
for example).But actually, it´s not a recommendable practice. In the case you do want to ensure the integrity of a file and you forget to update the file permissions, it will be modifiable by the group. It's against the "secure initial values" principle of security.
What you could do instead is make all the newly created file of a specific directory writable by the group. You can do this manipulating the ACLs of the directory. For example,
setfacl -dm u::rw,g::rw,o::r ~/shared
.Look at those posts for reference : https://serverfault.com/questions/349145/can-i-override-my-umask-using-acls-to-make-all-files-created-in-a-given-director and https://stackoverflow.com/questions/580584/setting-default-permissions-for-newly-created-files-and-sub-directories-under-a.