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.
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
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.
This is the second time i've had this occur to me.
I am working on a rails app, and I create a file via touch show.html.haml, and I can do an ls and see the file.
but I am using both WinSCP and SFTP for sublime, and neither can see this file!
WinSCP returns...
and Sublime returns,
Downloading folder "/app/qa/www/htdocs/qa-dashboard/app/views/scripts/" ... 1 file to download
yet it never downloads the file. What is happening here? I've also verified that it wasn't the touch command. i've tried vi'ing the file, and saving it. Same thing.
I've also verified that the hosts are matching.
Additional notes:
I am using elevated_user to create the file, and user, ddavison to edit the file. ddavison is not in the group.
File modes are,
drwxrw-rw- ... .
drwxr-xrwx ... ..
-rw-rw-rw- ... show.html.haml
The permissions on your scripts directory appear to be incorrect:
drwxrw-rw- ... .
^--^-- missing eXecute bit
The execute bit on directories allows the directory's contents to be listed. Since the "group" and "other" perms on the scripts directory do not allow listing, you'll get that error. Most like you're logged in to the shell as the owner of the directory, so you can get listings all you want, but you're logging in as a user OTHER than the owner via winscp, so they're unable to list the directory contents.
I expect the problem is with the permissions on the containing directory -
drwxrw-rw- ... .
Both of those programs probably try to chdir into that directory before retrieving the file. In order to do so, the directory must have x (execute) permissions for the user they are logging in as. Based on what you said, it seems that set 'other' needs +x -
chmod o+x /app/qa/www/htdocs/qa-dashboard/app/views/scripts/
Depending on the users/groups in question, you may want to consider removing write permission -
chmod o-w /app/qa/www/htdocs/qa-dashboard/app/views/scripts/
For directories, the x permission bit isn't execute, rather it's "list the contents of this directory". Since the directory's permissions are only 'rwxrw-rw-', only the owner may list the contents of the directory. Provide "other" that permission using chmod o+x /app/qa/www/htdocs/qa-dashboard/app/views/scripts.
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.
At my office, we have a network directory structure like this:
/jobs/2004/3999-job_name/...
/jobs/2004/4000-job_name/...
The issue is that employees rename the "4000-job_name" folders (which in turn breaks other things that rely on the name being consistent with a database).
How can I stop users from renaming the parent folder while still allowing them full control of that folder's contents?
Please keep in mind that this is a Samba share that Windows users will be accessing.
I think you want to do this:
chmod a=rx /jobs #chdir and lsdir allowed, modifying not
chmod a=rwx /jobs/* #allow everything to everyone in the subdirectories
Since the directories /jobs/* are in fact files in /jobs their names cannot be changed without the write permission for /jobs. In the subdirectories of /jobs/ everyone is allowed to do anything with the commands above.
Also, be sure to set the permissions of new directories to rwx as you add them.
(edit by Bill K to fix the examples--the solution was correct but he misread the question due to the strange coloring SO added)
The question has already been answered, so I'm just gonna make a brief remark: in your question, you use the terms "folder" and "directory" interchangeably. Those two are very different, and in my experience 99% of all problems with Unix permissions have to do with confusing the two. Remember: Unix has directories, not folders.
EDIT: a folder is two pieces of cardboard glued together, that contain files. So, a folder is a container, it actually physically contains the files it holds. So, obviously a file can only be in one container at a time. To rename a file, you not only need access to the folder, you also need access to the file. Same to delete a file.
A directory, OTOH, is itself a file. [This is, in fact, exactly how directories were implemented in older Unix filesystems: just regular files with a special flag, you could even open them up in an editor and change them.] It contains a list of mappings from name to location (think phone directory, or a large warehouse). [In Unix, these mappings are called links or hardlinks.] Since the directory only contains the names of the files, not the files themselves, the same file can be present in multiple directories under different names. To change the name of a file (or more precisely to change a name of a file, since it can have more than one), you only need write access to the directory, not the file. Same to delete a file. Well, actually, you can't delete a file, you can only delete an entry in the directory – there could still be other entries in other directories pointing to that file. [That's why the syscall/library function to delete a file is called unlink and not delete: because you just remove the link, not the file itself; the file gets automatically "garbage collected" if there are no more links pointing to it.]
That's why I believe the folder metaphor for Unix directories is wrong, and even dangerous. The number one security question on one of the Unix mailinglists I'm on, is "Why can A delete B's files, even though he doesn't have write access to them?" and the answer is, he only needs write access to the directory. So, because of the folder metaphor, people think that their files are safe, even if they are not. With the directory metaphor, it would be much easier to explain what's going on: if I want to delete you from my phonebook, I don't have to hunt you down and kill you, I just need a pencil!
If you make the parent directory--/jobs/2004/--non-writable for the users, they won't be able to rename that folder.
I did the following experiment on my own machine to illustrate the point:
ndogg#seriallain:/tmp$ sudo mkdir jobs
ndogg#seriallain:/tmp$ sudo mkdir jobs/2004
ndogg#seriallain:/tmp$ sudo mkdir jobs/2004/3999-job_name/
ndogg#seriallain:/tmp$ cd jobs/2004/
ndogg#seriallain:/tmp/jobs/2004$ sudo chown ndogg.ndogg 3999-job_name/
ndogg#seriallain:/tmp/jobs/2004$ ls -alh
total 12K
drwxr-xr-x 3 root root 4.0K 2009-03-13 18:23 .
drwxr-xr-x 3 root root 4.0K 2009-03-13 18:23 ..
drwxr-xr-x 2 ndogg ndogg 4.0K 2009-03-13 18:23 3999-job_name
ndogg#seriallain:/tmp/jobs/2004$ touch 3999-job_name/foo
ndogg#seriallain:/tmp/jobs/2004$ mv 3999-job_name/ blah
mv: cannot move `3999-job_name/' to `blah': Permission denied