I have been reading about Security of Design. I noticed a tip of lowest permission level. So I did the above code to my junk files. Unfortunately, the junk-folder seemed to contain some server files. A few sites become forbidden. The folder contained stuff such as "Mail", "dev" and "Public". The reason for junking them was that they are empty.
The files are located in a server of a CS-dept. There is no special CMS or anything like that. Before running 'chmod 644 some_files', I am promth to ask your opinion.
Why did the sites become forbidden? What are the lowest permission levels?
Lowest possible permission level is of course 000. But that wouldn't make much sense.
600 rw------- for private files
700 rwx------ for private directories
711 rwx--x--x for directories with public files, but without permission to list dir
644 rw-r--r-- for publicly readable files
755 rwxr-xr-x for publicly readable dirs
The web server usually runs as a different userid from "real" users. So you make it so that a "real" users files aren't readable by anybody else, and the web server can't read them. That's why 744 is a better permission set for files the web server needs to see.
Most likely the owner of the folders that are forbidden is another than the ones that are available. The user that runs the file or it's group must have read (and sometimes executable) permissions on the files/folder. Since you removed the read, write and executable privileges on the group and the world no one but the owner of the files will be able to run them.
TLDR:
Wrong owner of file/folder. chown to correct user.
Your problem: your user account does not have execute permissions for the rest of the world.
Solution:
You need to put the permissions 701 for your user folder. You can also set them to 711.
It is the folder which contains your public_html etc.
Then, check that your public_html has the permissions 755. Similarly, the contents should also be 755 in public_html.
Related
we are going to create a housekeeping script in e.g. PARENT_FOLDER.
In PARENT_FOLDER there will be many different folders and files with different owners.
Please let me know what would be the proper permission solution for this scenarion. I assume the better is to set +wx on PARENT_FOLDER, but I'd like to ensure this is the only option as security is the most important thing for me.
Thanks,
Alex
Make sure to assign the correct permission to the folder that you are going to manage. If you will only bye the administrator of the directory PARENT_FOLDER then you should assign the permission (rwx-r-x-r-x). (chmod 775 PARENT_FOLDER)
Then with the sub-directories you have to assign the permissions you want for each user and add the folder to each user with chown -user -directory.
So in this way every user will have only access to edit their own files in his directory.
I would like to know what is the best, correct and recommended way of doing chown and chmod to website files and folders.
I recently started working on linux and I have been doing it in the site root directory like the following:
sudo chown www-data:www-data -R ./
sudo chmod 775 -R ./
I know it is not the best way. There is a protected folder which should not be accessible with browsers and should not be writable, so I did the following to protected folder:
sudo chown root:root -R protected/
sudo chmod 755 -R protected/
Is it correct? If anything can be improved please let me know.
Read your command again. What you are saying is "make everything executable" below these directories. Does an HTML or gif to be executable? I don't think so.
Regarding a directory which should not be writable by the webserver. Think of what you want to do. You want to revoke the right to write a directory from the webserver and the webserver group (and everybody else anyway). So it would translate to chmod -w theDir. What you did is to tell the system "I want root to make changes to that directory which shall be readable by everybody and the root group". I highly doubt that.
So I would suggest having the directory owned by a webserver user with only minimal read access, it should belong to a group (of users, that is) which is allowed to do the necessary of the modification. The webserver does not belong to that group, as you want the outside world to be prevented from making modifications. Another option would be to hand over all the directories to root and to the editor group and modify what the webserver can do via the "others" permission group. But what to use heavily depends on your environment.
Edit:
In general, the "least rights" policy is considered good practice: give away as few rights as possible to get the job done. This means read access to static files and depending on your environment php files, read and execute rights for cgi executables and read and execute rights for directories. Execute rights for directories allow you to enter and read it. No directory in the document root should be writable by the webserver ever. It is a security risk, even though some developers of bigger CMS do not seem to care to much about that. For temporary folders I would set the user and groups to nobody:nogroup and set the sticky bit for both user and groups.
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)
I'm setting up a development workstation that used to have only one shared account to have an account for each developer that may be using it.
We commonly switch workstations. I would like to have certain directories "shared" by all users in a transparent manner.
I created /usr/local/share/workspace and /usr/local/share/rvm directories, which are symlinked to ~/workspace and ~/.rvm.
Subdirectories/files that are created within the directory should also be writable by all developers by default (without having to use sudo). I also would prefer not to set the directory to be world writable, since ruby gives me a warning because the rvm directory is on the path (I don't care about the security implications however).
How do I do this? Are there any resources that outline good practices?
If you want to share the directory on a single workstation, put all relevant users in a group (see man addgroup, and /etc/group), then run "chgrp -R yourgroup yourdir" on your directory trees. To give write permissions, run "chmod -R g+w yourdir".
If you want to share it between different computers, you can use NFS. See for instance this HOWTO.
I'm assuming that /usr/local/share/workspace and all contained files/directories are owned by a group that all of the users are in. If that's true, then all you need to do is apply the setgid and group execute bits to every directory, and also set the group write bit on every file and directory:
find /usr/local/share/workspace -type d -exec chmod +s {} \;
chmod -R g+wX /usr/local/share/workspace
The setgid bit, when applied to directories, means that:
All files and directories created in the directory will have their group ownership defaulted to the owner of the directory.
All directories created in the directory will also have their setgid bit set, so that this is effective for new directories as well. (In other words, this bit gets applied recursively to new directories automatically.)
Users will also need to supply a umask that permits write access to other group members. So they should put something like umask 002 in their ~/.profile. If they don't, then any files or directories that they create may not be writable by other group members.
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