|File Permissions Inheritance|
chmod and htaccess
| 1:46 am on Jan 23, 2005 (gmt 0)|
After some research (in these forums) and on the web, I learnt more but didn't find what I really need to understand.
Maybe someone here can spell it out with the right words, I saw I was not the only one with a lack of understanding on this issue.
My basic lack of understanding centers on inheritance and how this is determined.
This all came up because I moved some domains to a new provider.
Domains on my "old" provider are on a shared host (vps), but I had my own apache configuration to do and never saw any other users, and never had any problems setting permissions with chmod.
The new provider is also a shared host, and moving up the tree a step you can see other users, this was new to me.
Via htaccess using limit/allow/deny at the myname user level, I can see that other users on this shared host (group level) can see and search (=read & execute) but not delete or replace (=write).
I decided not to let other users see my files so changed the permissions on usr/www/users/myname to chmod 701 (and users/home to 711). Maybe this is the cause of further problems, but I need to understand why.
Below this user directory I have say:
I uploaded all my domain files and programs from the old privider to the new via my pc.
Set permissions for all programs in dir2/cgi-bin to chmod 755.
One of the programs builds files to dir1, I discover it doesn't work unless I set permissions to each and every file in each subdir to chmod 777.
This is impractical. I tried using CuteFtp to set permissions for dir2 using chmod -R 777 but that gives a syntax error.
Using the -R parameter I had understood all subdirectories and files would inherit the permissions. Without that working it would take a month of sundays to set permissions as needed on all files.
Then I tried deleting all below dir1, setting dir1 to chmod 777 via ftp, then reuploading all the subdirs and files to dir1, figuring they would inherit permissions from dir1, but no.
New idea. In one of my perl programs (which is in dir2/cgi-bin) I have a routine to set permissions (system("chmod -R 777 $data_dir");), but that doesn't work either, and I conclude this is because the program itself does not have the authority to set permissions.
So, it all comes down to inheritance.
For practical purposes, how can I give that program in dir2/cgi-bin owner level authority so it can set those permissions?
That will get me on my way.
But I want to understand, could someone explain how inheritance works and how it intertwines with htaccess at different levels.
thanks for any help.
| 3:09 pm on Jan 23, 2005 (gmt 0)|
I would personaly stay away from a hosting company that needs 777 access for data files. On unix level this means that you, your group and all others have write access to it.
If your hosting company did a decent setup, try if 606 works for your datafiles. In this case you have read/write access to the files, but your group doesn't. In most cases all user accounts of a virtual host are in the same group, so this will block the access from other users to your datafile. The 6 at the end allows other users to read/write to the datafile. In a good hosting setup, the WWW server will run in a group "nobody", or something like that, not in a normal user group, so this will grant the WWW server access to your datafile.
Never, no NEVER make your files in /cgi-bin/ 777! This allows other users to overwrite them with every content they want, including scripts to delete all your files, use your account for hacking, spamming or creditcard number sniffing. This is a big DON'T.
| 3:25 pm on Jan 23, 2005 (gmt 0)|
No the host does not require 777 for data files.
I wanted to make my html files in dir1 777.
No data files are in cgi-bin and none are 777. There are only programs in cgi-bin and all 755.
Sorry if my post was unclear about any of that. The program I mentioned in dir2/cgi-bin makes html pages in dir1.
I am just interested to know how inheritance works.
| 3:38 pm on Jan 23, 2005 (gmt 0)|
chmod works on one-file basis only. .htaccess propagates through the whole directory structure.
One thing you might consider is putting your datafiles in some difficult to guess directory like /data/qwer1234abce/datafiles and than chmod 701 your /data directory. No-one except you can see the contents of this /data directory, so it will be very difficult to guess the name of the subdirectory structure below. However, you have to be sure that the name of this directory will never show up in one of your visible webpages. Embedding in perl files in /cgi-bin/ is probably save as they are always parsed by the WWW server but...
You could also use "umask 070" in your perl sources. Umask sets the default protection mask for files created by the perl script". I am not sure how to implement this in Perl, I have used it in normal Bash shell scripts called by CGI scripts, but I don't know exactly if umask is a built-in command for perl or you have to call it as an external command. Some googling on the words "perl umask protection" might give a definite answer to this. I umask works it is a good solution, because it sets a one time protection mask for the script execution and all following file operations in the script will use these file permission settings instead of the default system settings.
HTML files with 777 permission are also not a very good idea. Although they cannot be executed as scripts on most WWW servers it still gives other the possibility to change the contents.
| 3:58 pm on Jan 23, 2005 (gmt 0)|
OK I'll experiment with htaccess at different levels, since that apparently gives inheritance and chmod does not, the simple answer.
I'll check out umask, that sounds like a good idea, although I don't understand why umask would work whilst a line in the perl program
system("chmod -R 777 $data_dir");)
| 4:13 pm on Jan 23, 2005 (gmt 0)|
Your perl call "chmod -R 777" requires the caller to be the owner of the file (or run with root permissions which is highly dangerous). In 99.9% of the cases the WWW server is not running as the same user as your hosting account, so the call has no effect.
"umask" sets the default file permission rights of the calling process, and every process has the right to change these default settings. So it doesn't change permissions on files directly, but it changes the behaviour of the process when creating new files. Perhaps I forgot to tell this: umask only works for new files, not for existing files. Existing files need to have the right permission already. The directory where the file is created must have write permission for the WWW server user, otherwise the creation fails.
.htaccess can in my opinion not be used in your case as it changes the access behaviour based on IP and browser identification, but it cannot change the access rights of individual files. I.e. if you did a chmod 000 of one file, there is no way you can change .htaccess in such a way that you can access it. Unix file permissions take precedence over .htaccess settings.
| 5:04 pm on Jan 23, 2005 (gmt 0)|
Thanks again lambert.
OK I get the gist, thanks very much, I'll work on it.