What am I doing wrong with my linux commands?

Question

I want to inherit every new file from my group so that I can have execute permissions, and no one else, but when I try to create new ones, it gives me 664 permissions how can I fix this??

sudo adduser $USER cyber_espionage  
sudo chown $USER:cyber_espionage ~/Documents/tool
sudo chmod 775 ~/Documents/tool
sudo chown $USER:cyber_espionage -R ~/Documents/tool
sudo chmod 2700 -R ~/Documents/tool
sudo find ~/Documents/tool -type d -exec chmod 775 "{}" \;
sudo find ~/Documents/tool -type f -name "*.py,*.sh" -exec chmod +x "{}" \;
sudo find ~/Documents/tool -type f -name "*.sh" -exec chmod +x "{}" \;

Answer 1

Background

You need to set your file permission mode mask using the umask command. Once you do this any new files that you copy into your respective directory will have the permissions set so that only the permissions bits enabled via umask will be propagated through to the newly copied files.

$ umask
0022

# -or- symbolically

$ umask -S
u=rwx,g=rx,o=rx

The above states that the permissions g=w or o=w will be omitted (turned off, effectively). See this U&L Q&A titled: Execute vs Read bit. How do directory permissions in Linux work? for more on permissions if they're unclear.

NOTE Unix umask can be a somewhat confusing topic, because it's a mask, so it's masking out permissions bits, rather than stipulating what bits to use, you're saying which bits you don't want.

To put it more succinctly:

the umask only applies an extra mask to the permission bits of the file to be created. The permission bits of the file is primarily determined by the program creating the file, specifically by the mode parameter to the creat() or open() system calls. The execute bit is normally not set if there is no reason for it (like creating an executable file). No value of umask can add bits not specified by the creating program; umask only resets bits.

Your issue

Now back to your issue, let's touch afile:

$ touch afile

$ ls -l afile
-rw-r--r-- 1 vagrant vagrant 0 Jul  8 11:45 afile

In the above the umask being set to 0022 stipulates that the permissions for group will have the 2 bit turned off (that's write) and the 2 bit off for other (that's write).

If we set the umask to 0007 and delete and re-touch the afile:

$ umask 0007; rm -f afile; touch afile; ls -l
total 0
-rw-r----- 1 vagrant vagrant 0 Jul  8 11:56 afile

The permissions are now such that other users have no access to the file (0007). This is because we've turned on all the bits (rwx) for the other component of permissions and are "masking" them from being set via our umask setting.

To restrict other users from accessing your directories through the Unix permissions, set your umask 0007 to restrict the "other" group of users.

NOTE: If the files are set with a Unix group that other people are members of, they'll still be able to access the files. To restrict these set the umask to umask 0077.

References

• Set the default permission
• https://en.wikipedia.org/wiki/Umask
• Execute vs Read bit. How do directory permissions in Linux work?

Answer 2

so that I can have execute permissions, and no one else

...
chmod 2700 -R ~/Documents/tool

That's enough already. Following this command, only your user (and the superuser root) can gain access to ~/Documents/tool/ and the files inside it.

You don't need to change the files inside to access mode 700. So you didn't need to use the -R option of chmod here. And you don't need to fiddle with your umask.

Firstly, your current umask of 0002 is already good for general purpose use.

Secondly, if you rely on a certain umask, you're going to be unpleasantly surprised e.g. if you notice that umask is reset for GNOME Files, Text Editor etc (e.g. inside Gnome 3 on Fedora 28, as started from GDM). These apps run inside a systemd --user service (they are started through dbus.service), and are hence affected by this systemd issue: https://github.com/systemd/systemd/issues/6077 Unfortunately there is no way to reconfigure it reliably.

You don't need to create the new group either - unless you want to grant access to some other users by putting them in the group.

If you intended to add other users to the group and use this to grant them either read (and execute) or read+write access, you would need some different steps. You would not use a mode ending in 700, since that only allows access by the owning user.

For the group write access case, if you wanted to be able to use apps which work like GNOME's to create such files, you would also need to implement a workaround for the systemd issue. The problem with the systemd user services is that they have their umask reset to 0022 instead. I say again, there is no way to reconfigure this reliably.