CHMOD setting to hide directory - linux

Just wondering what the most common CHMOD setting used to hide a directory and it's contents inside a public_html folder of a Linux server. Basically just so the public can't access the files at all. Thanks.

On directories, to hide the contents, executable permission is what allows people to view the contents of the directory. So if you want the owner and group to be able to read it, then permission should look like this: drwxr-x--- (chmod 750 the_dir).

Related

How to make a folder/directory undeletable/unremovable for a user but still writable

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

bash housekeeing script needed permission to delete different folders and files in folder

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.

Potential issues of chmod 777 on a directory?

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/

Why is my new file not showing up?

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.

'find . -exec chmod 700 "{}" \;' made sites Forbidden

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.

Resources