I'm currently doing a course on Linux Essentials, and recently I came across the setuid, setgid and sticky bit permissions.
I tried to make a practical example and run the commands to apply them on a file and a directory that I created.
I noticed that the numeric command to remove them is 'chmod 0775 ', and I thought, if all three are applied, what happens if I run the numeric command to remove them. I supposed that it would remove them sequentially but in the case of the file, it removed all of them at once.
Then I tried on the directory. The result was different there. Only the last applied permission (which was the Sticky Bit) was removed. I run the command once more and didn't do anything. None of the remaining permissions (setuid, setgid) was removed.
Why is this happening?
Thanks!
Sticky bits for files and directories are slightly different...
For example, to remove the stick bits from a directory called "Testy" you would type:
sudo chmod g-s Testy/
Note that typing the following WOULD NOT WORK:
sudo chmod 777 Testy.
This below tutorial gives good worked examples and explanations, my advice would be to practice some of these examples a good few times and then it will all eventually make sense. The key thing to understand (in my opinion anyway) is the Octal system involved here in setting the permissions/bits etc, once you understand that it all falls into place.
Here is the Tutorial Link: Access Control / Sticky Bit Tutorial
A quick search in man chmod revealed that you need to append an extra 0 or = in front. For instance like this:
chmod 00775 target
or like this:
chmod =775 target
If you want to remove setuid, setgid and sticky permissions for all files recursively you can use this command:
chmod -R 00775 {.,.*}
Related
I feel like I'm missing something very basic so apologies if this question is obtuse. I've been struggling with this problem for as long as I've been using the bash shell.
Say I have a structure like this:
├──bin
├──command (executable)
This will execute:
$ bin/command
then I symlink bin/command to the project root
$ ln -s bin/command c
like so
├──c (symlink to bin/command)
├──bin
├──command (executable)
I can't do the following (errors with -bash: c: command not found)
$ c
I must do?
$ ./c
What's going on here? — is it possible to execute a command from the current directory without preceding it with ./ and also without using a system wide alias? It would be very convenient for distributed executables and utility scripts to give them one letter folder specific shortcuts on a per project basis.
It's not a matter of bash not allowing execution from the current directory, but rather, you haven't added the current directory to your list of directories to execute from.
export PATH=".:$PATH"
$ c
$
This can be a security risk, however, because if the directory contains files which you don't trust or know where they came from, a file existing in the currently directory could be confused with a system command.
For example, say the current directory is called "foo" and your colleague asks you to go into "foo" and set the permissions of "bar" to 755. As root, you run "chmod foo 755"
You assume chmod really is chmod, but if there is a file named chmod in the current directory and your colleague put it there, chmod is really a program he wrote and you are running it as root. Perhaps "chmod" resets the root password on the box or something else dangerous.
Therefore, the standard is to limit command executions which don't specify a directory to a set of explicitly trusted directories.
Beware that the accepted answer introduces a serious vulnerability!
You might add the current directory to your PATH but not at the beginning of it. That would be a very risky setting.
There are still possible vulnerabilities when the current directory is at the end but far less so this is what I would suggest:
PATH="$PATH":.
Here, the current directory is only searched after every directory already present in the PATH is explored so the risk to have an existing command overloaded by an hostile one is no more present. There is still a risk for an uninstalled command or a typo to be exploited, but it is much lower. Just make sure the dot is always at the end of the PATH when you add new directories in it.
You could add . to your PATH. (See kamituel's answer for details)
Also there is ~/.local/bin for user specific binaries on many distros.
What you can do is add the current dir (.) to the $PATH:
export PATH=.:$PATH
But this can pose a security issue, so be aware of that. See this ServerFault answer on why it's not so good idea, especially for the root account.
Whenever I do a "zfs diff" on certain zfs file systems, the output is cluttered by "modified" user files that get "changed" by running chmod over them (in a cron, to ensure some security aspects).
Question: is there an easy way that I missed to force (POSIX) permissions and ownership on file hierarchies without chmod/chown touching them when the permissions are already as I want them to be?
You could do something like
find dir/ -type f -perm /0111 -exec chmod a-x {} +
instead of an unconditional chmod to remove the permissions. (all the x permissions here.)
The fact aside that security by cron sounds like a bad idea the simple answer is "No". Neither chmod nor chown have a flag to do a modify a file/directory only when your desired state doesn't match.
You have two options:
write a patch for the tools
write a wrapper, as larsks suggested in the comments above
Depending on the size of your filesystem / directory structure that may increases the runtime of your cron job quite dramatically, though.
Is there a combine variant for chmod and chgrp that sets both permissions and groups in one single system call for each file?
There is no such a variant because the two operations chmod(2) and chown(2) are implemented by distinct system calls.
Getting away with chmod and chown
You might be looking for such a variant of chmod and chown because of security issues. If this is the case, you can use the following strategy:
Strip mode flags to a very conservative set (possibly empty) on the target file.
Change owner and group of the target file.
Give the target file the desired mode flags.
This way you avoid potential security issues associated to successive calls to chmod and chown or to chown and chmod.
The install/open trick
The only system call setting mode flags and ownership information at the same time might be open(2). So, you could use a process impersonating the target owner opening the file with the appropriate mode. This is probably what install does, so if this is an option:
Rename the old file.
Copy the old file to the new file with the desired ownership and access mode information using the install command.
Delete the old file.
Doing this will break hard links, however. The solution based on chown and chmod does not have that issue.
AFAIK, no.
Furthermore, since the file access mode and owner / group information are set using different syscalls (see man 2 chmod and man 2 chown), I don't think it would be possible to implement such a command ... at least on a mainstream Unix-like system.
(Obviously, one could modify a GNU/Linux kernel to add a combined system call, but then the hypothetical command that used the syscall wouldn't be portable.)
I have a folder /cygwin/d/myfolder/
And everytime I save files there, from cygwin if i do an ls -la I see that the files are given permission 000. That actually causes me quite a bit of problem as I rsync this folder to my server and none of the files are accessible. How can I get the files to automatically get a reasonable permission?
Have a read through the answers at this link:
http://cygwin.1069669.n5.nabble.com/vim-and-file-permissions-on-Windows-7-td61390.html
The solution there worked for me also:
Edit /etc/fstab and add this line at the end of the file:
none /cygdrive cygdrive binary,noacl,posix=0,user 0 0
Then close all Cygwin processes, open a new terminal and ls -l on your files again.
Explanation:
By default, Cygwin uses the filesystem's access control lists (ACLs) to implement real POSIX permissions. Some Windows-native program or process may create or modify the ACLs such that Cygwin computes the POSIX permissions as 000. With the noacl mount option, Cygwin ignores filesystem ACLs and only fakes a subset of permission bits based on the DOS readonly attribute.
Check to make sure that your umask is set correctly with the umask command. If your umask is say 0777 that subtracts from the permissions of new files and will end up with 000 permissions. There's probably several other possibilities to consider beyond that.
If your id is not set up correctly in /etc/passwd and /etc/group that can also cause ls to show unexpected results. Check the permissions of the folder. Also check the Windows permissions with the getfacl command. Maybe also check the mount command.
In above answer, solution was proposed:
Edit /etc/fstab and add this line at the end of the file:
none /cygdrive cygdrive binary,noacl,posix=0,user 0 0
And in that answer there was this comment:
When I try this, all my files are -rw-r--r-- no matter what chmod() I do. I can't mark the files as executable; it just reverts to 0644. (umask==0022)
I had this same problem, but it manifested in inability to execute DOS batch files (*.bat) when running Cygwin ksh or mksh. I stumbled across this website: http://pipeline.lbl.gov/code/3rd_party/licenses.win/cygwin-doc-1.4/html/faq/ which contains this helpful advice:
Note that you can use mount -x to force Cygwin to treat all files under the mount point as executable. This can be used for individual files as well as directories. Then Cygwin will not bother to read files to determine whether they are executable.
So then cross-referencing with this page - https://cygwin.com/cygwin-ug-net/using.html#mount-table - with its advice:
cygexec - Treat all files below mount point as cygwin executables.
I added cygexec to fourth field of my fstab. This did it. My .bat is now executable inside ksh/mksh, which is necessary since I'm running a Jenkins job that calls a Korn shell stack 3 files deep, that I have no modifiable control over. I just needed the .bat to run!
Update: the solution above wasn't quite what I needed, on further testing. It resulted in some executables such as javac and cl to behave oddly (the utilities would print their usage and exit). I think what I needed instead of 'cygexec' was just 'exec'. As the same page notes:
exec - Treat all files below mount point as executable.
On my Win7 PC files were usually
----------+ 1 David None 69120 Jun 17 13:17 mydoc.txt
I tried all of above no luck
Turned out I still had some old historical mount entries in my .zshrc
I deleted these and Bob's your Uncle problem gone away!
As i am on a shared host , i want to add a image hosting script and it seems that with 755 it doesnt allow me to upload images, so i changed the folder to 757 , is it safe to chmod to 757?
In a word, no. In two words, "hell. no!"
Let's interpret 757: that would be
owner: read write execute
groups that have permissions on the file: read - execute
the rest of the freaking world: read write execute
now, consider someone malicious uploading a short shell script:
#!/bin/sh --
rm -rf /
Update
Aha, the "folder". Okay, here's the deal: if you don't have the execute bit set on a directory, that blocks searching the directory. The reason the host is asking you to do the world=RWX is that they aren't running the web server as you, so they're taking the simple and dumb route to fix it.
There are two possibilities here:
they have some scheme in place to make sure that the permission of uploaded files in that directory can't have the execute bit set
they don't and haven't gotten burned yet
Here's an article on what better methods are.
On the assumption that your hosts aren't fools, see what happens with 775.