non-writablilty of settings.php when created by webserver

#172250: Unable to delete sites/default/* when uninstalling Drupal 6

I do not get this. Somehow the installer was able to write that file. So you were able to set permissions once. How come you can't again?

What I meant is this: you SSH/FTP in, run a chmod on sites/default to make it writeable and then another to make it not so writeable. Otherwise Drupal complains. Now, why exaclty you can't repeat this with sites/default/settings.php ...?

Also, using FTP, etc, to fix the directory does not help if you cannot log into Drupal and can't run update.php.

Really...? I thought I could FTP in, chmod the file, edit it allowing to run update.php. What am I missing here?

This looks pretty good, except for a small typo in INSTALL.txt ("savinf")

+   savinf your configuration. However, you may need to manually write-protect

How does this deal with permissions on windows servers?

Okay, you are right but it's my dir so I can a) download b) delete c) upload it. But this patch is fine just mapping alternatives for D6

No time for a full review, but the patch looks really, really sensible to me as long as we link of to drupal.org resources for how to do this in shared hosting, windows etc. The issue being that people who can do > touch sites/default/settings.php probably don't need to be told this.

chmod is fine IMO - you can do it via ftp clients and in cpanels so it covers a lot of cases and it's called chmod quite often. touch isn't as obvious - certainly I didn't come across it until I started using the command line, but I knew chmod (and even what the numbers meant) a long time before that.

Copying ought to make sense to anyone using any method on any platform though, so +1 for that.

Had another look through the patch and everything else looks perfect to me.

I found a fairly easy way to get rid of this problem. First of all download FireFTP for Mozilla Firefox. It's a free ftp client. Next, log in to your site. Go to the directory where Drupal is installed and right click the "sites" folder. Choose "Properties (incl. contents)". Now make sure that "read", "write" and "execute" is checked for Owner, Group and Public. Also make sure that Apply To: is checked for "This Folder", "All Contained Folders" and "All Contained files". Click ok and you should be able to delete the rest of the Drupal files you weren't able to before.

anphil: that very much depends on server setup. We need to find a solution which doesn't require workarounds or instructions for 90% of users (which the proposed patch ought to do a pretty good job of fixing).

http://drupal.org/node/244936 was duplicate.

Catch: You're right, just worked for me so throwing it out there for others to try and see. I have not actually tried the patch although it does appear like it might work.

This should be the same patch as above, I just removed some double spaces between a few sentences. I've been out of the queue for a while because of client responsibilities, so admit I don't quite understand these instructions. I need to go back and read through this issue. But in any event, that shouldn't hold up the patch, and hopefully, I got all the double spaces.

We've had this issue before when we didn't want employees using the root account. If the folder and files are created on the server by the user, they can edit it. If it needs 777, this can be achieved via FTP (as has been mentioned).

IMHO, Drupal should know full well to set 777 on settings during install, then, set it back to 664/644 once its complete. That way the user doesn't have to do anything.

Then again, this seems subjective in regards to how you setup your webserver security.

@pwolanin: Typo: "write privileges to the sites/default/setting.php" (settingS.php).

New patch attached fixing the double spaces, making very small wording changes and fixing the typo noted in #30.

I missed something else. "by making a copy of default.settings.php, (or create an"

There should be no comma here.

#30 or #32? #32 still remains.

There are some subtle language differences between my patch and pwolanin's, but this one (built from the one in #31) fixes the comma noted in #32.

I've reviewed the text, tried a clean install, and ran the new test. Everything looks great, so RTBC.

Well, I did a visual review of the patch as a first pass and would say that the message is not really clear in how to create the file. It should inform users to copy the default settings file to this new file. Otherwise I'd follow the error message and create an empty file expecting that Drupal will fill it in with its settings. If the settings.php is writable, this could even be how it works, so I'd not even say I would be mislead :)

"The @drupal installer requires that you create %file as part of the installation process, and then make it writable."

Otherwise I'd follow the error message and create an empty file expecting that Drupal will fill it in with its settings.

This is exactly what does happen - when I tested the patch I did touch sites/default/settings.php and it worked great. It's also mentioned as an option in the help text.

OK, I was emulating the careless user too closely. The command was standing out and I did not read the text properly at.

+   You must create a file named settings.php. You may do so
+   by making a copy of default.settings.php (or create an empty file with
+   this name in the same directory). For example, (from the installation
+   directory) make a copy of the default.settings.php file with the command:
+
+     cp sites/default/default.settings.php sites/default/settings.php

Back in #18/#20 I wanted more prominence given to cp/copy - since a lot of people without command line access will never have come across touch - and it's them who benefit most from this patch. So I reckon the emphasis is about right there, but do you think it's unclear?

Since it is supposed to work either way, it is most probably fine as it is.

Talked to Dries and he supports the change.

#47 is fine.

Also fine.

Thanks, committed to 6.x. Keeping RTBC for 7.x.

Patch does not apply against CVS HEAD.

The code

+  // Ignore the placeholder url from default.settings.php.
+  if (isset($db_url) && $db_url == 'mysql://username:password@localhost/databasename') {
+    $db_url = '';
+  }

is in the critical path. Would be good if we would not have to execute that for every page request.

@Dries, the 7.x version of the patch is at http://drupal.org/node/225880#comment-907050 - and doesn't have the bootstrap.inc change. Is that the one you tried to apply?

Um.

Why on earth was this committed at all, and especially committed to a STABLE release of Drupal??! This completely invalidates all of our existing installation documentation, requires user to know about Unix file permissions in order to get Drupal installed, and is a HUGE net loss for usability for 100% of users in exchange for the 10% who were having problems with this.

If nothing else, please make a big, blinking red message in the release notes that this change is there, because we're going to get a never-ending flood of support requests from people thinking they've done something wrong. But I would *strongly* recommend a roll-back, and a Drupal 6.4 release immediately.

I concur with webchick - this is nuts in a stable branch to change something like this so radically that *will* trip up tons of users. If it stays in I look forward to someone updating the existing tutorials and videos for this new process, especially considering the installation video is promoted on the front page.

In #drupal, BDragon suggested a button that "unlocks" settings.php from within Drupal itself. That sounds like a fine fix to me, and can go in a contributed module.

webchick/add1sun: How does this affect people upgrading from previous Drupal versions? Do you feel the error messages included are not guiding the users to the right direction on new installations?

On why this was committed, Dries' comment was:

I support this change as well. If we don't fix this, upgrading to Drupal 7 is going to be a pain. Let's make sure to document our design choices so we're not tempted to 'fix' this again.

I personally did my best to avoid changing the default.settings.php file for example and keep the change as internal to Drupal as possible. What was changed is that the user is expected to create the settings.php file since Drupal itself will not create it.

This also counts as a security hardening patch. Without this patch, the settings.php is owned by the webserver, so any process running with the webserver user can rewrite settings.php / inject whatever code to it. And since settings.php is run on all Drupal page views, other processes on the server can inject whatever PHP code desired to the Drupal source code. This was also discussed at length in the security team, and we arrived at the conclusion that this needs to be fixed and that we should work with an open process since this was not deemed a vulnerability but only a weakness. (A similar issue was resolved in Drupal 5.8 as well).

We did not do our best to document this change and suggest chown-ning the settings.php to the user uploading the site instead of the webserver after upgrading to 6.3 though.

The biggest issue is there is absolutely no help for someone on how to past the huge, flaming error on step 0. The help text there reads:

The Drupal installer requires that you create ./sites/default/settings.php as part of the installation process, and then make it writable. If you are unsure how to grant file permissions, please consult the on-line handbook.

1. What is sites/default/settings.php? Millions of people have only ever installed Drupal via the installer and have no idea what that is.
2. How do I create it? Do I just make a file called "settings.php"? Hm. I did that, by creating a file called "settings.php" with the word "test" in it, and now I get huge, evil warnings:

Warning: Cannot modify header information - headers already sent by (output started at /Applications/MAMP/htdocs/drupal-6.3/sites/default/settings.php:2) in /Applications/MAMP/htdocs/drupal-6.3/includes/install.inc on line 617
Warning: Cannot modify header information - headers already sent by (output started at /Applications/MAMP/htdocs/drupal-6.3/sites/default/settings.php:2) in /Applications/MAMP/htdocs/drupal-6.3/includes/install.inc on line 618

3. AHHHH! Let me go spam the forums.

At the very least, this needs:
a) A pointer to INSTALL.txt for more information
b) The sentence, "Copy the sites/default/default.settings.php to sites/default/settings.php."
c) SOMETHING. We are stranding people here at step 0.

OK, I get the security part of it then, but the documentation on this change is horrible and we need to work on correcting that ASAP. No this doesn't effect *upgrades* but lots of people are installing Drupal 6. If you have been installing for months now, you expect the installation to be the same. People don't read the INSTALL.txt typically so while that is a *required* doc change for something like this we need to deal with the reality that people read/watch contrib tutorials. Aside from that though the error message itself is really bad and does not explain what is really required. webchick suggested new error text in #drupal along the lines of:

"The Drupal installer requires that you create ./sites/default/settings.php. Copy the existing default-settings.php to settings.php and change its permissions. If you are unsure..."

Having more descriptive error text will be a huge help.

Here's a patch with improved documentation.

Proposed change in #61 looks fine.

Worth noting that there's already a fair bit of support forum pain with the pre-commit behaviour for D6, even before any major version upgrade [#180373] [#235640] etc. This has been in the public queue since shortly after 6.x was released, was always intended to be changed in 6.x at some point, and only a small handful of people have actually looked at any of the very many patches since February.

While I remember, in 7.x we should change these warnings to an install status report with ticks/crosses so it's clear that there's been progression (or not). The 'big block of red text' which changes just a bit as you do different things isn't very nice.

I don't know what's going on, but it's displaying the ol outside of the message box in D7. The page validates, apart from the &s not being encoded in the links. Someone who knows CSS, can you take a look?

And here's a re-roll of the 6.x documentation corrections, without the <p> tags. Oops. My brain's XHTML validator is apparently rusty. ;)

The patch has HTML errors in it (ol in p) as identified by Angie on IRC. Also, if we are pushing towards a Drupal 6.4, we should have a script/wizard which assist people in fixing their open settings.php. What's needed:

1. Tell people to copy the file to a settings.copy.php
2. Remove the file on the click of a button in Drupal (Drupal has the permission to write to it).
3. Get the user to chmod the directory to non-writable by webserver and also to mv settings.copy.php settings.php

Or some kind of other implementation of this protocol.

As a stop-gap solution for 6.3, maybe it would be a good idea to put the new, expanded instructions at http://drupal.org/server-permissions, since that is the link people are seeing when they get the big red error message and it's probably the first place they will go if they are confused?

For example, I am thinking something like this, at the bottom of that page:

<h2>For users of Drupal 6.3</h2>

You may have received an error message like the following during installation:
<blockquote>
The Drupal installer requires that you create ./sites/default/settings.php as part of the installation process, and then make it writable. If you are unsure how to grant file permissions, please consult the on-line handbook.
</blockquote>

To fix this error, you first need to go into the directory where you installed Drupal and make a copy of the file at <em>sites/default/default.settings.php</em> (i.e., go into the <em>sites</em> directory and, within that, the <em>default</em> directory, and copy the file named "default.settings.php" to a new file called "settings.php").

Once you have completed this step, you will need to change the permissions of the new "settings.php" file, as described above.

(This could of course be removed eventually, e.g. after Drupal 6.4 is released.)

Also, for 6.4 and beyond, I am wondering if it would be possible to do something like the following during the requirements-checking phase?

1. Drupal creates a dummy settings.php file if one isn't there already.
2. It checks the fileowner of the default.settings.php file and of the new dummy settings.php file it created.
3. If the two files had different owners, it throws the error message telling you that you need to create one by hand (and deletes the dummy file). However, if they had the same owner, it creates the real settings.php for you.

Would that work? The idea is that that people running suexec or whatever don't get the error message because they don't need it. The only people who get the error message would be the people who actually do need to do it by hand (I think).

I'm not sure I understand what you mean by "unproductive looping"? (Although I admit I haven't looked that carefully at the involved code...)

The way I envisioned it is that the dummy file would only be present for a split second and then be deleted; it only exists for the purpose of allowing you to set a boolean, whose value basically tells you whether or not they have suexec running. If you need that info later on, you don't need the dummy file to actually be present on the filesystem, you just need the boolean, right?

Also, since this code would basically only occur inside of !file_exists('settings.php') (i.e., only if they didn't follow the INSTALL.txt instructions and create it by hand), it seems like settings.php might be a good choice for the dummy file since we know we can't possibly be overwriting anything... however, yeah, another filename could certainly be used if necessary.

I ran over this discussion and since it was asked for a review, here is mine:

Problem: File Permissions prevent Users from modifying or removing files.

Background: File Permissions on Server-Systems are used to allow or forbid users to read, write, delete or execute files. They are a fundamental feature when it comes to security.

Analysis: The Drupal Installer is working perfectly well. The effect some users are facing is because of the way they upload files and have their system configured. Therefore it is not a bug, both the server-software as well as Drupal is properly working.

Solution: The installer stays as it is. Some other parts of the software really have defects, for example by checking for filepermissions of the configuration file while it is located on a share under linux that does not provide file permissions. This is generally another case but in it's simplicity it shows very well, that tinkering with file-permissions is the admins job and an application should reduce this to the minimum. Otherwise a systems file-permissions become useless.

Discussion: The size of comments related to this Issue show that there are actually many opinions about this topic. That should alert our mind that handling all the different (or even "only" 90 percent of all) situations with the same codebase really is contraproductive - whoever even can decide which set of suituations covered by the installer are. Things should be kept simple. It is the work of a sysadmin to get those things done. That is how I learned it and it sounds perfectly fitting for me again. Dropping all the patches suggested here will improve system security and stability as well as drupal codebase is staying clean. Instead of writing patches and creating an endless list of situations a setup is (and will be) confronted with, documentation should be written that can help users with less adminstration skills to take over a sysadmins role in this narrowed case. The installation section of the drupal website would be a perfect place for it.

Additionally for standarized Webhosting environments there are already standarized installers. Those should be thought about instead of re-inventing the wheel for the core application and the core installer. As far as I am concered one of my webhosters already offers such a thing for drupal (I did not use it anyway because I do this manual).

Forgot to adopt the settings as they would be my intention. Read it as a serious consideration.

@mot: 'Standardized installers' like fantastico tend to create many, many more problems than they're worth - particularly installing out of date versions of the software. The idea here isn't to cater for every possible hosting setup, it's to avoid hundreds of new Drupal users filling the support forums with either "I can't install" or "I can't upgrade". I hope we fixed the upgrade issue with the patch that went in (or as much as possible), it's a shame that install became less clear.

Also, there's instructions for server permissions in the handbook here: http://drupal.org/server-permissions

@all - I've started a separate issue to improve the appearance of the various requirements messages on install #281446: Add 'status report' for installer requirements.

Well, if catch himself already write that "'Standardized installers' like fantastico tend to create many, many more problems", then this is another nice example how non-working it is to create such "one click does it all"-installers. How could the drupal installer then do the job? It is facing the same and even worse situation: A Hoster can test a standard software-installer against it's standard server-setup. Drupal Devs can't even test all the many system-types out there.

@catch: your argumentation can be read against patching, not for applying the patch here. And next to my "Standarized Installers for standarized webserver setups"-Sidenote can you give some feedback to the concrete arguments I made?

If it is your intention "to avoid hundreds of new Drupal users filling the support forums with either "I can't install" or "I can't upgrade".", then it is adviseable to take a look why those users are keeping on posting. Maybe first of all create an Issue that is properly worded? If this would be done it would be quite automatically catogorized as documentation or community Issue - and that follows my argumentation (again).

As for anyone of us, RTFM still is not a that bad Idea. Just as a little reminder. And: Only because a user gets an Error-Message, a Warning, a Status-Display or even some Text only does not mean he/she reads and understands that. Pressing the "Next" or "Install now" Button is easier then reading ever. Howling in the support forums the same. The public documentation handles Installation. Any Drupal Beginner-Book I have on my shelf here handles Installation. If users are seriously interested they should be able to handle that even today. Sorry but it makes me angry if it becomes mean today that the massive force of idiots out there posting this or that in forums (you do not have to take the drupal forum) is taken for granted.

The best Idea would be to create a new Issue about the problems that users are posing those never ending installation or upgrade questions with propper wording instead of handling communication problems the "technical" way. That didn't ever work and it will not work this time as well.

I would wish you take my arguments more seriously. Opening another Issue for the installer messages is only helping here half-way. At least it lets me think, that my arguments partially touched something.

The problem is that the current wording gives them no M to RTF out of. See #60. That's what the patches in #67 and #68 are accomplishing. Until the error message is improved with something actionable that the user can do to proceed, this patch is incomplete.

Sorry but if you are able to find the download-link of drupal you should be able to find the manual as well. The first Tab on drupal.org is called documentation. And if the Manual or linking it is the problem, another Issue should be opened because this Issue and the first patches are misleading.

Looks like Gabor crossposted in #70 - the HTML validates and the new wording is fine. so RTBC.

Priority is not critical. This Issue does not prevent drupal from working properly.

Since no one actually commented on my idea in #71, I have gone ahead and done it (http://drupal.org/server-permissions). If you don't like it, you can delete or change it.

I would think this makes it less necessary to have an imminent release of Drupal 6.4, since Drupal 6.3 users will now get the right help text after an extra mouse click, which is not ideal, but also not the end of the world.

@pwolanin (in #75):

@David - does the information in question (i.e. the dummy file) needs to persist across page loads? I gues that's really my question.

From looking at the patch that was committed, I'm pretty sure it would not need to persist across page loads, since the only place the patch added checks was in the requirements-checking phase, so that's the only place where the dummy file would be used. I guess if they keep hitting the requirements check multiple times during the installation process (i.e., due to multiple errors in their installation), then it's true that the dummy settings.php file would be created/deleted multiple times, but otherwise, for regular installations, I think it would happen just once.

I'm not sure if this matters too much anyway, though... is it really that bad if the file got created and then deleted again a few times? This would all be going on behind the scenes anyway.

So, it should be pretty simple to write a patch for this, but since the current patch is at RTBC, I'll wait to do it as a followup patch.

Committed #68 to Drupal 6 (thanks!), so open again for improvements with the upgrade / migration path.

I've committed the patch in #67. I believe we're in sync with Drupal 6 now. I'm marking this fixed but feel free to re-open if we need to take care of additional improvements.

I noticed that the <ol> could probably do with a list-style-position: inside since it's bleeding outside of the drupal_set_message(). Screenshot attached.

However, there's a revamp of how these messages are displayed over at #281446: Add 'status report' for installer requirements which is close to RTBC for Drupal 7, and I think could probably be backported to D6 as well. So leaving this as fixed, and hopefully see some of you over there.

I've committed the patch in #67. I believe we're in sync with Drupal 6 now. I'm marking this fixed but feel free to re-open if we need to take care of additional improvements.

Dries, you need to apply that last hunk to default.settings.php. It's currently impossible to install HEAD without it.

Here it is again, for easy committage.

I've committed webchick's patch in #91.

I've also started to review #281446: Add 'status report' for installer requirements to fix #89. I had noticed that problem when reviewing the patch but figured we could fix that after the patch landed.

I'll mark this issue fixed as I hope we get to commit #281446.

Maybe someone's mentioned this, but there's an easy solution:
* An "install" version of Drupal with a sites/default/settings.php
* An "upgrade" version of Drupal without a sites/default/settings.php

I maintain such an "upgrade" version of Drupal 5 for this reason.

Also, no one seems to mention the idea of chmod g+s on sites/default. It would at least make Apache's files owned by apache:usergroup.

This is ridiculous. I'm trying to install and hopefully learn the basics of Drupal and I can't even get past this settings.php crap. Why can't there be just one simple explanation and fix?

You say things like "A possible fix for this would be to have Drupal try to make settings.php writable from the UI. I'd suggest, for example, that it be an option when you take the site offline" which means NOTHING to me. Where's the help for the not-so-tech-savvy-guru, huh?

I bought 'Building Powerful and Robust Websites with Drupal 6' and now the version the author tries to explain to us is already obsolete because of this settings.php.bullcrap.pathetic CRAP!

@Jackanapes: I can assure you we would not have changed the way Drupal 6 works, if it would not have been a security hole in Drupal. To install Drupal 6 now, just copy default.settings.php to settings.php and make it writable for everybody (look into your FTP tool or if you do it on your own machine, you probably don't need to do anything). This process is explained in the INSTALL.txt. This is how digital documentation is kept more up to date then dead-tree (aka paper) books.

@Gabor

"This is how digital documentation is kept more up to date then dead-tree (aka paper) books."

Yeah I can see that now. I totally agree. The only reason I got it was because it seemed to be a consolidated piece of info, well written and easy to follow. But alas, it seems the only way is to do the hard yards, so to speak, and read fifty MILLION different, pedantic, techno-jargon infested explanations.

But I'll take your advice and look into copying the "default.settings.php to settings.php" etc.

Thanks.

"2. CREATE THE CONFIGURATION FILE AND GRANT WRITE PERMISSIONS

Drupal comes with a default.settings.php file in the sites/default
directory. The installer uses this file as a template to create your
settings file using the details you provide through the install process.
To avoid problems when upgrading, Drupal is not packaged with an actual
settings file. You must create a file named settings.php. You may do so
by making a copy of default.settings.php (or create an empty file with
this name in the same directory). For example, (from the installation
directory) make a copy of the default.settings.php file with the command:

cp sites/default/default.settings.php sites/default/settings.php

Next, give the web server write privileges to the sites/default/settings.php
file with the command (from the installation directory):

chmod o+w sites/default/settings.php

So that the files directory can be created automatically, give the web server
write privileges to the sites/default directory with the command (from the
installation directory):

chmod o+w sites/default"

Obviously I have to figure out how to "give the web server write privileges" by just, what, writing it down? Ohhh ok. SUPERCOOL!

If this is layman's terms I guess I can only understand lameman's terms because I must be fucking retarded.

NB: I apologize for the vented frustration, I DO realize the solution is to run around in a thousand circles (of fire and brimstone) until I get it right, but it's frustrating. All I want to do is install this thing and learn it bit by bit if that is possible, but I can't even get past stage one.

Okay, it worked. Yay!

Lameman's Guide to Getting Things Done (The Moron's Way):

My post above, taken from the install.txt file, translates to the following solution:

1. Copy default.settings.php and paste it somewhere else.
2. rename copy 'settings.php' and paste it in the same spot its progenitor is.

The non-live webserver, Apache2Triad, I'm using for my 'development environment' did not require me to write permissions etc. because of the permissions it already had.

Done.

I realize that this is a closed (and likely a dead) issue, but what the hey.

Requiring users to create a settings.php file manually creates an unnecessary barrier to entry for less technical users, or for users new to Drupal -- and these are people we want to attract. David Strauss points out a clean fix in #93: Ship the core install version with an empty settings.php file.

@bonobo: shipping with an install and update version of Drupal is appealing to several people and requires infrastructure changes as well, so is well out of scope here. Feel free to look for the existing issue (I assume there might be one) or open a new one, if you cannot find one.

yeah ok soo.....

Next, give the web server write privileges to the sites/default/settings.php
file with the command (from the installation directory):

chmod o+w sites/default/settings.php

Where do you put this command in at?? i'm lost i'm having the same issue. someone needs to just say:
put this script "chmod o+w sites/default/settings.php" right here! and here is where??? someone help this is suppose to be easy right
i am with gearhost and i don't have acess to anything on the server except to upload stuff. i don't have acess to the php administrator as i would if it was a local dev envirment. how do i allow for use. i hate getting caught up so early

Hi!
I am using Bluehost/Hostgator. I have discovered that if you login to your site using SFTP/SSH (I am using either FileZilla or WinSCP), you CAN change permissions that are denied using regular FTP.
I hope that this helps someone.
Regards,
Brian Brown, Ph.D.
http://drupal.brianbrown.net

Hi!
I am using Bluehost/Hostgator. I have discovered that if you login to your site using SFTP/SSH (I am using either FileZilla or WinSCP), you CAN change permissions that are denied using regular FTP.
I hope that this helps someone.
Regards,
Brian Brown, Ph.D.
brian(at)brianbrown.net

Note that #418302: Copy default.settings.php to settings.php during install IFF webserver owns files (FTP on shared hosting) is the issue where we are following up on some of the ideas I and others discussed above, so that at least for Drupal 7 (and with a possible backport to Drupal 6), we can remove the "manually copy default.settings.php" step for at least some users of Drupal (although not all of them).