Use ACLs to remove the permissions. In this case, you don't need to modify the permissions of all the executables; just remove the execute permission from /usr/bin/ to disallow traversal of that directory and therefore access of any files within.
setfacl -m u:guest:r /usr/bin
This sets the permissions of user guest to just read for the directory /usr/bin, ...
sudo chmod 700 /bin && sudo chmod 700 /bin
would only change the permissions on the /bin directory itself, or if it’s a symlink, the directory it points to. This would make the contents of the directory inaccessible to non-root users, but the damage is limited.
You can recover by logging in as root, or booting into a rescue environment (...
If any of the files has additional hard links located outside the 600 directory, they will be able to access those files using that alternate path. But this won't give them access to any of the other files.
But if the hard links don't already exist, there's no way for them to create them, since creating a hard link to a file requires access to the directory ...
Given that there are no other mechanisms (e.g. ACL, xattr?) play a role then on a extX-file system you should be save.
Nevertheless, a careless modification to the permissions or the directory could leave your files exposed.
You should consider using Access control lists for that. Also not having executable permission on the directory will prohibit non-root users from accessing the directory. Again, check ACLs.
How to manage ACLs on Linux
Yes you can brute force such a directory.
Unix was originally created in a very co-operative environment, so a set of permissions that said don't browse here would have been respected.
If the users of your machine don't have that sort of culture then (assuming you can't change your users) don't create directories with execute permissions if you want to ...
What are you trying to do? Forbidding use of the system's standard commands to some user is just incivil behavior in the extreme... commands that could put the system in jeopardy are far in between, and have been carefully vetted for security. The permissions on files should stop most attempts at mischief.
Consider giving them a restricted shell (check the ...
By default, *’s expansion will ignore files starting with a ., so if you name your file in that manner, sudo rm -rf * won’t delete it:
See Why do shell globs omit dot files by default? for details.
How can you run a command (e.g. iftop or similar) that requires root
privileges from a non-root user and without using SUDO in front?
There are at least 2 methods you can use to allow
non-root users use iftop but both of them require root access.
The safer method is to assign cap_net_raw capability to iftop binary:
sudo setcap cap_net_raw+ep "$(...
The permissions of a new file are set from (1) the permissions set in the open() call modified by (2) the umask of the creating process, so that bits set in the umask are zeroed. That is, a permission bit is set only if allowed by both of those, it's just that the bits in umask are inverted.
In your case the users probably have different umasks, namely A ...
If they can do that, is there really a point in e.g setting 711 permissions on a home folder to protect its content while allowing access to things like SSH keys? (I've read people advise this.)
Then either (a) they were misguided, or (b) you have probably comprehended only part of the advice.
OpenSSH (at least) requires that SSH keys have restricted ...
Run visudo and look for a line with the nagios username. Someone may have given restricted sudo permissions. If you see a line like the following you can add /usr/localcw/bin/check_disk.sh to the list
## Allows nagios user to run below commands
added to list
## Allows nagios user to ...