It sounds like you're describing the setgid bit functionality where when a directory that has it set, will force any new files created within it to have their group set to the same group that's set on the parent directory.
Example
$ whoami
saml
$ groups
saml wheel wireshark
setup a directory with perms + ownerships
$ sudo mkdir --mode=u+rwx,g+rs,g-w,o-rwx somedir
$ sudo chown saml.apache somedir
$ ll -d somedir/
drwxr-s---. 2 saml apache 4096 Feb 17 20:10 somedir/
touch a file as saml in this dir
$ whoami
saml
$ touch somedir/afile
$ ll somedir/afile
-rw-rw-r--. 1 saml apache 0 Feb 17 20:11 somedir/afile
This will give you approximately what it sounds like you want. If you truly want exactly what you've described though, I think you'll need to resort to Access Control Lists functionality to get that (ACLs).
If you want to get a bit more control over the permissions on the files that get created under the directory, somedir, you can add the following ACL rule to set the default permissions like so.
before
$ ll -d somedir
drwxr-s---. 2 saml apache 4096 Feb 17 20:46 somedir
set permissions
$ sudo setfacl -Rdm g:apache:rx somedir
$ ll -d somedir/
drwxr-s---+ 2 saml apache 4096 Feb 17 20:46 somedir/
Notice the + at the end, that means this directory has ACLs applied to it.
$ getfacl somedir
# file: somedir
# owner: saml
# group: apache
# flags: -s-
user::rwx
group::r-x
other::---
default:user::rwx
default:group::r-x
default:group:apache:r-x
default:mask::r-x
default:other::---
after
$ touch somedir/afile
$ ll somedir/afile
-rw-r-----+ 1 saml apache 0 Feb 17 21:27 somedir/afile
$
$ getfacl somedir/afile
# file: somedir/afile
# owner: saml
# group: apache
user::rw-
group::r-x #effective:r--
group:apache:r-x #effective:r--
mask::r--
other::---
Notice with the default permissions (setfacl -Rdm) set so that the permissions are (r-x) by default (g:apache:rx). This forces any new files to only have their r bit enabled.
Granting 775 permissions on a directory doesn't automatically mean that all users in a certain group will gain rwx access to it. They need to either be the owner of the directory or to belong to the directory's group:
$ ls -ld some_dir
drwxrwxr-x 2 alex consult 4096 Feb 20 10:10 some_dir/
^ ^
| |_____ directory's group
|___________ directory's owner
So, in order to allow both alex and ben to have write access to some_dir, the some_dir directory itself must belong to the consult group. If that's not the case, the directory's owner (alex in your example), should issue the following command:
$ chgrp consult some_dir/
or to change group ownership of everything inside the directory:
$ chgrp -R consult some_dir/
This will only work if alex is a member of the consult group, which seems to be the case in your example.
This will not allow ben to access all of alex's directories for two reasons:
- Not all of alex's directories will belong to the
consult group
- Some of alex's directories may belong to the
consult group but alex may not have chosen to allow rwx group access to them.
In short, the answer depends both on group ownership and on the group permission bits set for the directory.
All of this is provided you don't use any additional mandatory access control measures on your system.
Best Answer
The nobody user is a pseudo user in many Unixes and Linux distributions. According to the Linux Standard Base, the nobody user and its group are an optional mnemonic user and group. That user is meant to represent the user with the least permissions on the system. In the best case that user and its group are not assigned to any file or directory (as owner). This user is in his corresponding group that is (according to LSB) also called "nobody" and in no other group.
In earlier Unixes and Linux distributions daemon (for example a webserver) were called under the nobody user. If a malicious user gained control over such a daemon, the damage he can perform is limited to what the daemon can. But the problem is, when there are multiple daemons running with the nobody user, this has no sense anymore. That's why today such daemons have their own user.
The nobody user should have no shell assigned to it. Different distributions handle that in different ways: some refer to
/sbin/nologinthat prints a message; some refer to/bin/falsethat simply exits with 1 (false); or some just disable the user in/etc/shadow.According to Linux Standard Base, the nobody user is "Used by NFS". In fact the NFS daemon is one of the few that still needs the nobody user. If the owner of a file or directory in a mounted NFS share doesn't exist at the local system, it is replaced by the nobody user and its group.
You can change the permission of a file owned by the nobody user just simply with the root user and
chown. But at the machine hosting the NFS share, that user might exist, so take care.I also use a Synology system. They run the apache web-server under the nobody user.