I'm deploying nutch. At first I just left the index file under /root/nutch1.0. This works fine when run from command line. However, when I search from web, it always returns 0 hit.
I finally found the reason: It's because the index file is located under /root that causes the failure to open the file. Things returned to normal when I move the index file to another directory.
But my question is:
I didn't change the permissions of the index file (just cp xxx another-directory). Why did the access rights change?
drwxr-x--- 12 root root 4096 Jun 1 14:49 root
drwxr-xr-x 14 root root 4096 Nov 16 2007 usr
I put files under /usr and it worked.
To read a file, you need search ('x') permission on the directory the file is in, as well as read permission on the file itself. Moving the file from a directory where the web server does not have search permissions to one where it does will cause the effect you see.
Because you can't access anything in the root directory unless you're root.
Look at the permissions on /root, it should be something like 700... the execute bit is set so than only root can "execute" the directory. Execution permissions on a directory are what allow you to look at files inside the directory.
It's the same reason you can't "ls /root" while you're logged in as someone else.
Presumably you're in group "root", and therefore can use the directory. When using a web interface, you're likely in a program with its own user (in the Unix/Linux sense), which is probably not in group "root". From the permissions you've listed, anybody can use the "/usr" directory.
Related
This is needed for a case when it is necessary to create a folder in home directory of a user, to allow user read/write/remove files in the folder, but not allow to remove the folder itself (considering a regular user and not a sudoer).
In my case (i.e. RedHat) it was not enough just to put a file with root rights inside user`s folder, because the user owns the folder.
In my case if a user owns (or has all permissions on) a folder, he can remove it even with root file or empty folder inside.
I have made quite a number of experiments including playing with chown and permissions like 400, 000, o+t, 1775 etc. Initially I did not want to use chattr.
Meanwhile I have found a solution, which I share as an answer below; a variant that suits my needs so far.
Here is the solution I found myself.
Basically it uses the fact that when root subfolder is not empty, the user cannot remove it anymore.
In the below example superuser (root) each time creates (if does not exist already) a folder with user rights in user`s home directory, then puts inside a folder with root rights (if does not exist already), and inside that root folder puts a file with root rights.
## prepare directory for the external configuration
EXT_CONFIG_PATH="~user/.EXT_CONFIG"
mkdir -p ${EXT_CONFIG_PATH}
chown user:user ${EXT_CONFIG_PATH}
chmod 555 ${EXT_CONFIG_PATH}
mkdir -p ${EXT_CONFIG_PATH}/.rootguard
chmod o+t ${EXT_CONFIG_PATH}/.rootguard
touch ${EXT_CONFIG_PATH}/.rootguard/.rootguard
chmod 400 ~user/.EXT_CONFIG/.rootguard/.rootguard
Due to a recent hack of my servers I am in some kind of ultimate restriction taste and thus wanted to limit the permissions of all the root folders like so:
chmod o-x /*
To enable login for other users again, I do:
chmod o+x /home
Now, I have another user which is not root and which should be the only one allowed to login, but it cant - the SSH authentication itself works but then this error appears:
/bin/sh: Permission denied
Seems easy to grant permissions to the bin folder like so:
chmod o+x /bin
But I still get the same Permission denied message.
Whats going on here?
The execute bit (x) on directories allows an user to go into that directory. If you remove the x bit from the root directory (/), then it is not possible to go into that directory and get the details of its contents. But in order to get the details of the bin directory under the / directory, that is necessary.
The same is true for /home and what is in it, by the way.
You might argue that you can do an ls / and list it's contents. That is because the contents itself are in the inode of the listed folder. But try to get a detailed listing with ls -l / and you will see that the permissions can not be listed. This is because the permissions are in the inode of the bin directory, but without the x permission, you are not allowed to enter the root directory in order to look at that inode.
Removing the x permission bits from the root directory is going to cause lots of problems. Don't do it! Better to learn concepts like SELinux or similar.
I have created directory and set read only permission for root using chmod.
chmod -R 400 some_dir/
but when I try to create any file inside it using touch, I was expecting error message something like
touch some_dir/hello.txt
"touch: cannot touch `some_dir/hello.txt': Permission denied"
but it creates file "hello.txt" inside it happily, but directory permission if I check it still shows readonly for root. Please explain what I'm missing here, since I was expecting error message which would be displayed if any other user(apart from root) try to create file in that directory?
PS: I'm running as root user.
Short answer is - Yes, Root user can create files in a directory that is marked as Read Only. You may argue - why? But that's the whole point of root account. It's a special user and it can do things that others can't.
If you want to prevent the file from accidental modifications, you can set the i attribute of the file on with chattr +i command. This will make the file unchangeable. However, note that it will only prevent accidental modifications. Root users can still just unset the attribute first and then modify the file.
I have a directory that I want to share in a cluster so that another user can
use my program and do some changes to her needs.
I have root access and I just basically did
$sudo cp dir /home/visitors/usr1
When I checked the directory and their contents, I found that they belong to root, which was good so far, so I did
$chown *.* usr1
Now the directory and the files belong to usr1 and with the same permissions that I had originally, namely
-rw-r--r-- 1 usr1 users
(also the group is the same as mine).
Now, when I try to edit a file as usr1 in emacs, the window stays empty and below I can see a message:
Creating directory: permission denied, /home/visitors/usr1/.emacs.d/
If I try to edit a file, but using vim, I can save changes, but a warning is raised:
E138: Can't write viminfo file /home/visitors/usr1/.viminfo!
Any idea how to override this type of behaviour and be able to edit normally in both vim and emacs?
The error messages do not say anything about not being able to read or write the file you are editing; your usr1 does not seem to have write permissions on /home/visitors/usr1. Check with
$ ls -ld /home/visitors/usr1
The files that cannot be written do not match *.*, they are .*
I think you need to change permission on those as well. Try ls -la and see what the owner and permissions are.
I want to prevent a user from modifying a file but I can't seem to get it to work using standard permissions.
The file is file.jpg, which is in the folder 2012/.
File details:
-r--r--r-- 1 root root 10294 Feb 19 2013 file.jpg
Folder details:
drwxr-xr-x 2 charly charly 36864 Aug 27 15:38 2012/
My intention is to prevent the user from renaming the file but with the permissions as they are he's able to.
What am I missing?
You don't change a file when renaming it or moving it in the same filesystem, because a file is really an inode (which may have zero, one or more filenames in directories).
Renaming a file is an operation inside the relevant directories (not on the file itself). Perhaps removing write access to the directory might help (but if the user owns the directory, he could change again these permissions on the directory with chmod). Read also more about sticky bit on directories.
BTW, the user could also hard link that same file, i.e. add a new filename to it. Then each filename is refering to the same file.
The permissions on a file prevent/allow access to the file. Renaming a file does not involve changing the file itself - renaming is actually a change to the directory.
Try changing the directory permissions to:
dr-xr-xr-x
and see what happens.