By rboklewski on
We are receiving an error in the status report, which says:
Configuration File
The directory sites/default is not protected from modifications and poses a security risk. You must change the directory's permissions to be non-writable.
Well, I changed NTFS permissions to deny all users except for system the write permission and still this error persists. I am running IIS7 under Windows Vista, what could be the problem. I have searched the internet for the last 45 minutes and found nothing pertaining to the error.
[Removed all caps from title: nevets]
Comments
this must be a new one ;)
this must be a new one ;)
nobody?
nobody?
Hello, go to DOS, cd to the
Hello,
go to DOS,
cd to the site folder
input: attrib +R default
I worked for me. I am using IIS6 on W2003
It worked
Thanks! I've been trying to figure out this issue for weeks.
Question: will I ever have to put the write permissions back on?
not working under II7 and Windows 2008
not working under II7 and Windows 2008
I'm still getting:
"Configuration file Not protected
The directory sites/default is not protected from modifications and poses a security risk. You must change the directory's permissions to be non-writable. "
this worked
thanks
IIS 6.0 win2003
ditto -thanks! for posting
worked for me Windows Server 2003, IIS 6, and Drupal 6.x
Hello, go to DOS, cd to the
Thanks! worked for me too!
i have the same problem.
i have the same problem. attrib +R not working for me. the folder ist write protected under windows but i get still get the error.
my system is vista IIS7. may be its a drupal bug?
server 2008
I am also using IIS7/Server 2008, and the error will not go away.
Appears to be a bug
I am having the same problem with Drupal running under Apache on Windows Server 2003.
This appears to be a bug in Drupal that has been fixed for the next release. See developer discussion of this issue at http://drupal.org/node/312677.
"the next release" not meaning "of any production-ready version"
"the next release" being Drupal 7, rather than 6.anything. This blows, it's very clear by now that this particular problem is unfixed and unfixable (by non-core-hackers) on IIS7.
fixed using windows explorer and folder properties
running windows 2003 and iis6. same message with a 6.8 fresh install. in windows explorer i opened up the folder properties and checked the read-only attributes checkbox, applied, clicked okay. the message disappeared.
i don't think the message is referring to the iusr_machinename acl entry (in the security tab). the earlier cmd usage of "attrib +R default" does the same thing without using the gui.
I'm still having this
I'm still having this issue.
Anybody knows if it has already been solved?
Thanks.
same issue here in ii7 /
same issue here in ii7 / server2008. i beleive it has somthing to do with the install process
yeah.. same here: IIS6 and
yeah.. same here: IIS6 and Drupal 6.10
Repeat issue
except using Windows 2003 and Apache 2x. I'll assume it is protected according to the file permissions I set - read only and read only for the user
Same Problem - My work-around
I have installed the lastest versions of drupal (6.8-6.11) on a Windows 2008 server running IIS7 and have the same error on the status report page. I have removed the error by hacking one of the core files. I first tried to chmod every possible way me and the sys-admin could find. I finally tracked the issue to what I believe is a PHP file check glitch.
My solution was to change the file modules\system\system.install @ line 105. I commented out the "$conf_dir = drupal_verify_install_file(conf_path(), FILE_NOT_WRITABLE, 'dir');" line and replaced it with "$conf_dir = TRUE;"
As I have read all over this site, hacking the core files in not recommended, but I was sick of seeing this error message everytime I viewed the reports. I hope this helps.
REMEMBER: This is not a solution to FIX the problem, only a work-around for the displayed error message.
IIS 6 solution already provided
@kinderpera - April 22, 2009 - 09:55,
please see sxlderek - August 4, 2008 - 02:58 above.
But, it doesn't work on IIS 7.
Windows Server 2003, IIS6 solved
In order to resolve this on
In order to resolve this on my machine I did two things.
1. attrib +r to the default folder at the cmd prompt.
2. added the IIS_WPG user to the default folder from the Security Tab on the Default's folder properties. Then I specifically denied write for that user.
Rereshed the status and no more warning.
Now I do not know what ramifications this will have later as I am new to Drupal. But will keep this in mind if I have write issues later on.
Ok, I made the error go away,
Ok, I made the error go away, but it is results in a security problem.
For IIS7 (Vista/Win2008/Win2008R2)
Make sure the identity that is running the site has full control over the sites\default directory. Click on your site, open 'Authentication' feature. Select 'Anonymous Authentication'. Click 'Edit'. Usually 'Specific user' is selected and set to IUSR. If so, you can add IUSR to have full control over sites\default and the error will go away. You can also set the anonymous identify to Application Pool Identify, in which case get the username from 'application pools', and give that user full control.
The solution makes the error go away, but it will let drupal modify the directory. So don't do it. :)
Solution for protect from modifications
Has anyone solved this. I have 10+ installations that are running great on Windows 2008 R2 and Drupal 6.15. I even did a clean base install with the Aquia version that Windows installs from the Web Platform Installer 2.0 to see if it helped, to no avail. Fortunately, it did install a new version of PHP 5.2.12 that came with Wincache (replacing the APC version I was using). My Drupal sites have a dramatic speed boost from it. Windows hosting people might want to check it out. Just need to get rid of that silly error for the permissions every time I go to the admin screen.
Permissions
IIS_IUSRS must have write permissions to settings.php - it happened to me after drupal upgrade on IIS7 W2K8
I still have that problem. Any solution?
I had an initial installation with Drupal 6.14 working without any error at the status report, and when I followed the upgrade path to the 6.16 version, appeared that error, and I have tried everything from this page, but I keep getting that error.
My installation is W2008 and IIS7.
I must note I have the issue with sites/default directory and not with the settings.php file.
I have tried the following (and probably another possibilities that I have forgotten now):
What really shocks me is that I have compared the php files involved in the error, and the lines involved are the same.
Anybody has a solution to this problem?
Perhaps I should file a bug?
Yes, I'd file a bug.
I just installed 6.16 clean on Win2K3, IIS 6, PHP 5.2.11, MySQL 5.1.36, and get the same thing. The file is marked read only, the folder and all children has had write privileges removed for all accounts in the ACL and IUSER_ is not even listed there.
Nothing I've tried removes this red error message from admin/reports/status.
same problem
I am having the same problem on iis7.5 running on windows 7.
Weird solution
W2008/IIS7
If someone has that problem, I have found an absurd way to disable that warning.
You have to allow the IUSR (not IIS_IUSR) the NTFS write right, and then you will see the warning going away.
I say it's absurd because is says it's protected when we have done almost the opposite of what is expected.
Does anyone have a better idea?
P.D: I have seen later that DraconPern achieved the same solution, but it can be constricted to the write permission.
Don't Do This!
That's not a solution. That's worse than the original problem.
The warning is a feature intended to warn you of a security flaw in your site. Deliberately creating the flaw for the purpose of making the warning go away is the absolute wrong thing to do.
It's better to look at the warning and know that you did indeed already correctly configure filesystem permissions, than it is to break filesystem security and wave bye-bye to the warning message. Talk about burying your head in the sand. Or cutting off your nose to spite your face.
protecting against writing by whom?
The whole point of the warning is that Drupal has discovered that it has the ability to write to a configuration file, which could be a hazard due to accidental or malicious usage. This same warning is raised in many Web applications, not just Drupal. Now, you must distinguish among who is the owner, who Drupal/PHP/the server are running as, and who is "everyone else". Drupal doesn't care if the "owner" (or even the "world") can write to the file, but is only concerned that it is able to write to it.
Unix-family systems are a bit clearer than Windows on who gets what permissions to do what. You have owner/user, group, and world/other permissions, each of which is some combination of read, write, and execute. There are some extras such as "suID" flags, but we won't get into that. You want to find who (as PHP, in particular) Drupal is running as, and make sure they have no "write" permission. This may or may not be the same as the "owner" (I've seen server and PHP set up to run as owner, in group, or as world). Of course, you want to deny write permissions to random other users, unless that's what the server and/or PHP are running as.
Windows seems to be a bit murkier (surprise!). attrib +r will set "Read-Only" permissions (remove "write" ability) for some group of users/applications, but I'm not that familiar with its intricacies. The key point again is that the file's "owner" may or may not be the same as who is running as the server and as PHP. Again, you want to deny the ability to write the directory or file to the executing program (and of course, if possible, random other users).
Needless to say, once you've made critical configuration files "read-only" for routine site operations, you will from time to time have to make changes (by editing, or by uploading a new copy). If the process of denying write permissions to Drupal have also denied them to you, obviously you need to temporarily restore "read-write" access (add "write" or remove "Read-Only") to at least the file owner. Once you've made your changes, don't forget to restore the "Read-Only" state.
The flip side of this protection of configuration files is setting permissions so that Drupal (PHP) can write to certain files or (more usually) directories in the normal course of operations, such as uploading of user attachment files. Here, you want to ensure that Drupal has write permissions in certain places (e.g., add "write" permissions to make a directory 777 instead of 755, or remove any "Read-Only" setting on it).
More discussion: http://www.catskilltech.com/freeSW/SMF/faqs > Proper Permissions
Error on MAC osX4.11 : Configuration file not protected
went to the Sites Folder
got info
changed permission to READ ONLY for owner.
ERROR
changed permission to READ ONLY for everyone: owner, group and user
ERROR
Changed back to just owner
ERROR: can't make it go away!!
Configuration file Not protected
The directory sites/default is not protected from modifications and poses a security risk. You must change the directory's permissions to be non-writable. The file sites/default/settings.php is not protected from modifications and poses a security risk. You must change the file's permissions to be non-writable.
OS X is Unix-family
See my reply just above (3183470, 9 July 2010 "protecting against writing by whom") for information that may be helpful in your case. OS X is Unix family based (Linux-like), so comments applying to Linux should apply to OS X.
Ok, an update to the
Ok, an update to the 'solution' that I proposed, but still secure.
1) Create a normal Windows user for your drupal install. Create a password too.
2) I recommend reseting the permission of your drupal install so that it inherits from c:\inetpub. I believe by default, Administrators, Trusted Installer, and SYSTEM have full control. Others will only have read & execute.
3) Add the windows user to the drupal directory and give them read & execute.
4) Create an application pool for your drupal install. Set the application pool's identity to your windows user, in IIS7 double click the new application pool and then Advanced Settings -> Process Model -> Identity
5) Set your website to use that application pool
6) Authentication -> Anonymous Authentication -> Edit -> Set to Application pool identity
7) Give the window user full control to the sites\default directory
8) Turn on readonly attribute on sites\default\settings.php Note that this is in the file's property, and not a security setting. It applies to all users regardless of their permission.
So, what all this does is give the drupal install privilage isolation. It can only write files in the sites\default directory, but not your settings.php. It can still create needed cache file, uploads, etc.
IIS7 on GoDaddy
I am on GoDaddy and have no access to the command line for this box running IIS7. I have used their file manager interface to set the directory to be read, not write, and I am still getting this error. Any solutions?
this works
this works
safe to proceed with public site?
Am I understanding correctly that this warning message in the Status Report (below) is NOT an actual security risk, but just an annoying bug? We have our first Drupal site almost ready for launch, and I want to make sure it is not vulnerable or fix the problem if it is. Thanks for reading - Clayton
Configuration file - Not protected
The directory sites/default is not protected from modifications and poses a security risk. You must change the directory's permissions to be non-writable.
What you should understand
What you should understand is:
Check it yourself and see if what it's saying about the configuration file and the sites/default directory is true or false.
In other words, the bug isn't in saying that this is a risk, the bug is in failing to report accurately when the permissions are actually correct. Just because it says they're not, doesn't mean they are. You have to check yourself and decide whether it's OK or not to proceed.
this is a bug in drupal 6.22.
this is a bug in drupal 6.22. i found on a clean install everything was normal if you follow install.txt instructions. however if you touch the default directories permissions it will flag it as writeable even though its not and there's no way to clear the error no matter what you do. probably some error in the DB.
This helped on upgrading to 6.24
chmod 755 default/Drupal 6.26 and PHP 5.3.13
I am running 6.26 and php 5.3.13 and all error and problems are gone (including the file upload issues with php 5.3). The issue with Drupal 6 in Windows show configuration file permission errors are gone as well. I did not change any file settings, but now Drupal show my configuration file as protected.
Change permissions on settings.php, not the directory
I had the same error today. No matter what permissions I set on the sites/default folder, it tells me they are too open. The only way is to make it not readable at all, but then it asks me to reinstall drupal, because it cannot read the settings.php
What solved the problem for me is to change permissions on settings.php to 444
It is a bug in drupal as it does not show the correct error message. I should point to settings.php instead of talking about the directory. If I had the energy I would file an issue report now...
Did the same here, but my
Did the same here, but my question is, does 6.26 run properly with 5.3.13?