Say a FOLDER is set to chmod 777 but FILES in the folder is set to chmod 755.
Non-owner user can write files to the FOLDER. Then how about overwriting the already existing files? Can the existing files be overwritten by a non-owner user?
If you give everyone read, write, and execute permissions on a directory, everyone can create and remove files, including ones that have been created by other users.
If you want to avoid such a behavior (one of your comments mentioned that), you should create another /tmp or /var/tmp directory: Set the sticky bit:
$ chmod +t directory
With the sticky bit set, every user can create new files, but is unable to remove files from others.
A fair word of warning here though: I do not recommend to secure your uploads with such a feature. Implement a better access control in your frontend instead.
Yes. While non-owners will not be able to open a file for editing and change its contents, they will be able to remove any file in the directory and replace it with a new file of the same name.
Related
I currently have a directory (udir), which has only read and write permissions for all users. This directory contains two files (file1 & file2)
I initially though that only write access was needed (on the directory) for me to be able to delete/remove a file via (rm udir/file1) but the rm command would give me access denied. when i set the permissions to read, write, and execute, the rm command works.
Obviously the execute access is needed as well but why??
I thought the execute access on a directory was to be able to make it a working a directory and search its contents and access sub directories.
You actually need read, write and execute permissions on the directory, not on the file itself since the operation is done considering the permissions effects of directories.
A good documentation can be found on this link, which mentions the below in the section Special Considerations on Directories:
To delete a file requires both write (to modify the directory itself)
and execute (to stat() the file's inode) on a directory. Note a user
needs no permissions on a file nor be the file's owner to delete it!
Assuming that I have this directory structure:
/tmp/mysockets/appname/
What are the security drawbacks to doing chmod 777 on /tmp/mysockets/?
Could another user delete or mess with the reference to the appname/ directory?
What I want to do is allow other users to add their own directories to /tmp/mysockets/ but I don't want to allow them to rename it or delete files/subdirectories which are already inside it (owned by another user).
I think you are looking for sticky bit, thats will do what you want. With permissions 777 you grant read/write permissions to everybody therefore the files can be removed/renamed
A sticky bit is a permission bit that is set on a directory that allows only the owner of the file within that directory or the root user to delete or rename the file. No other user has the needed privileges to delete the file created by some other user.
To set a sticky bit use following
chmod o+t /tmp/mysockets/
or e.g.
chmod 1757 /tmp/mysockets/
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 often finding myself in a situation where I login to shell as root (I've already been told it's a bad practice) and copy new files to some directory served by apache.
Since I'm logged in as root, the new files will have root set as owner, and different permissions than the files which are already present, and I'll need to change the permissions for Apache to be able to access the files. I am doing it manually.
I am researching a better way of doing it. I was wondering if there is a way to somehow apply with a single command the permissions of the current folder to all it's sub-folders and files.
Windows has such a feature, where you can "reset all files and folder permissions" to those of the parent folder.
To get the permissions on the current directory, you can use
stat -c %a .
To set permissions recursively, use
chomd -R
Put together, it gives
chmod -R `stat -c %a .` .
Or, you can use the --reference option of chmod if supported.
chmod -R --reference=. .
+1'd #choroba's answer but... are you sure that's what you want to do?
From http://en.wikipedia.org/wiki/File_system_permissions ...
Permissions
Unix-like systems implement three specific permissions that apply to each class:
The read permission grants the ability to read a file. When set for a directory,
this permission grants the ability to read the names of files in the directory,
but not to find out any further information about them such as contents, file type,
size, ownership, permissions.
The write permission grants the ability to modify a file. When set for a directory,
this permission grants the ability to modify entries in the directory. This includes
creating files, deleting files, and renaming files.
The execute permission grants the ability to execute a file. This permission must
be set for executable programs, including shell scripts, in order to allow the operating
system to run them. When set for a directory, this permission grants the ability to access
file contents and meta-information if its name is known, but not list files inside the
directory, unless read is set also.
The effect of setting the permissions on a directory, rather than a
file, is "one of the most frequently misunderstood file permission
issues".
When a permission is not set, the corresponding rights are denied.
Unlike ACL-based systems, permissions on Unix-like systems are not
inherited. Files created within a directory do not necessarily have
the same permissions as that directory.
(emphasis added)
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