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/
Related
how to set file permission to directory that directory permission is assign automatically to files under that directory when we create new file into the directory
please any one let me know who know the answer
I think you're asking about how to make files inherit permissions from their parent directory. I will assume you're using GNU/Linux (you've added the redhat and ubuntu tags), in which case this can be done from the terminal by assigning group ownership to the directory and getting the children (files) to inherit from there.
To do this:
Recursively set the directory permissions:
chmod -R <octal permission code> /path/to/parent_dir
Recursively change ownership of directory:
chown -R <you>:<yourgroup> /path/to/parent_dir
Set inheritance of group ownership with setgid bit:
chmod g+s /path/to/parent
Note that the setgid bit means that executables will run with the same permissions as if they'd been run by the group: see here. If you don't understand the permissions, the easiest way to find the chmod octal code (for a beginner) is with a calculator. This is also a duplicate and probably doesn't belong on here, but since I can't see it mentioned on stackoverflow (it is on the Ubuntu StackExchange and Super User StackExchange) I'll answer here :)
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
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.
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.
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)