I'm using a remote server via ssh. The problem is that all users can read and copy my user folder /export/home/yemino and its sub folders, and also I can read and copy their files (this last is not a problem).
I'm just an user (i.e. I haven't root privileges). And I want to have a work folder, for example /export/home/yemino/work only readable by my (and admin, of course) with my "secret" C codes.
What ways you know to do this?
You can create a directory with the mkdir command and afterwards you can use chmod to change the rights of other users to that folder.
You can do something like this:
mkdir testing
chmod -R 700 testing
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
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 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.
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 need to put the Dropbox folder inside the root path, this way:
cd /Dropbox
I can't create first a normal folder because Dropbox automatically creates a Dropbox folder nested in it...
so it would result in this (like It does now)
cd /folder/Dropbox
What would be the problem if I give a "sudo chmod +w /"?
So I could initialize Dropbox inside the root path?
No problem if other files would be written in the / since there are no important files loaded in there, and anyway users wouldn't be allowed to write in the subfolder like /etc. Is that right?