Weird permissions on settings.php causing issues

[whastings]

I've noticed that some sites built on the box have sites/default/settings.php set to weird permissions, such as 0444. This has resulted in two problems:

1. If you remove the site, it's directory will be left in /var/www as a result of being unable to delete settings.php
2. If someone updates settings.php in a site's repository, git pull will fail to update settings.php with the new version.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/3956094-weird-permissions-on-settings-php-causing-issues?utm_campaign=plugin&utm_content=tracker%2F235881&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F235881&utm_medium=issues&utm_source=github).

[reynoldsalec]

I think I've noticed this as well; the only way I'm able to remove
settings.php on some built sites is via Finder on the host machine.

On Fri, Aug 23, 2013 at 5:39 PM, Will Hastings [email protected]:

I've noticed that some sites built on the box have
sites/default/settings.php set to weird permissions, such as 0444. This has
resulted in two problems:

1. If you remove the site, it's directory will be left in /var/www as
   a result of being unable to delete settings.php
2. If someone updates settings.php in a site's repository, git pull
   will fail to update settings.php with the new version.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/54
.

Co-founder Kalamuna, LLC http://www.kalamuna.com
510.666.5489

[whastings]

So I verified that Drupal is repeatedly setting sites/default, sites/default/settings.php, and sites/default/default.settings.php to non-writable permissions. This happens whenever system_requirements() runs. The commit above fixes this for site removal via our drush crush command, simply by chmod'ing these to writable before removing the site's webroot directory.

Unfortunately, the issue of git being unable to update settings.php still exists. I was hoping there would be a git hook I could use to make it writable before the merge happens, but there's no pre-merge hook, only post. @patcon and @tizzo, have either of you encountered this type of issue before? We would definitely appreciate any insight you may have.

[tizzo]

Yeah, I've had that exact issue a number of times. I don't really know of a good fix. The way I've handled it is by ensuring that we never actually use the default site (we create a site folder for the local name (we use mysite.local)) and dynamically generate the settings.php file to be placed there. That way we do not get git conflicts. I think trying to use git hooks for this would be a bit of a hacky work around.

Also, I've encountered another issue on some machines where once the perms get changed the only way I have managed to get it back to a deletable state was to change the perm on the host system because the guest got blocked based on the way NFS user and group mapping was working.

The thing I have been planning to experiment with is whether we could do some magic in vagrant to detect the user and group running vagrant on the host and mapping that user to the vagrant user in the NFS mount so that this permission orphaning wouldn't occur. I don't think git hooks are the right way to handle this issue either.

[whastings]

Thanks so much for the insight Howard. It's definitely a tricky issue to solve. I agree a git hook would be hacky, and I didn't see a way to do it with one anyway. I like the sound of linking the guest user to the host group. Please let us know if you have any luck with that.

[pirog]

Thanks @tizzo ... we've contemplated a bunch of mostly gross ways to get this to "work" but thought we'd see if you and/or @patcon had any wisdom.

[patcon]

Sorry guys, we don't version-control the settings.php file either, so I don't really hit the git pull problem. Whenever we programmatically delete the docroot for something, we simply make sure that the script that does the deletion runs chmod 777 setttings.php beforehand. But yeah, can't be much help beyond that :)

[tizzo]

I've seen chmod 777 fail too depending on the host/client NFS share and
permissions.

On Tue, Sep 3, 2013 at 3:31 PM, Patrick Connolly
[email protected]:

Sorry guys, we don't version-control the settings.php file either, so I
don't really hit the git pull problem. Whenever we programmatically delete
the docroot for something, we simply make sure that the script that does
the deletion runs chmod 777 setttings.php beforehand. But yeah, can't be
much help beyond that :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/54#issuecomment-23740187
.

[pirog]

@tizzo we've observed similar behavior as well.

would love to not vc settings.php but we often put a lot of pantheon centric stuff in there.

[pirog]

Closing this because it should be addressed here now
https://github.com/kalamuna/terminatur

[tizzo]

Correct me if I'm wrong but these issues can result from the permission on settings.php getting set to the recommended permissions when in a file share (drush site-install will update the perm for example) such that the owner can't write to settings.php. Here the nfs mounted user looses the ability to ever change the perm back or remove the file, if that's what you're experiencing this might not be solvable in terminatur at all actually. Right?

[pirog]

Very well could be correct.

While testing terminatur late last night i did notice that trying to either
edit settings.php or remove sites/default after drush site-install produced
something like this although i am less sure now if it produced "exactly"
this. The issue i experienced was mitigated by having terminatur chmod
settings.php before write and sites/default before remove. I am going to
reopen this because i trust experts like @tizzo vs "glorified hobbyists"
like myself :)

Either way... tried to make Terminatur relatively kalastack agnostic ie
should be easy to get it to work with other stacks... of which i had
proviso most in mind.

[tizzo]

Yeah, I haven't looked into Terminatur yet. It looks to do a lot of the same things fetcher does (setting up vhosts, databases, etc) but looks to be pantheon specific? Fetcher doesn't support pantheon yet but aims to be platform agnostic.

We definitely have some overlap and I wonder if we should be collaborating on this stuff.

[patcon]

@tizzo is being modest, but he was speaking with one of the aegir maintainers, and @anarcat was saying that fetcher sounds pretty much like it's v3 of provision (which is the drush guts of aegir) :)

So hopefully there's an opportunity for a long-term collaboration between y'all. Whoop!

[anarcat]

that would be v4, actually, v3 is the d7 port. ;)

[patcon]

👍

[kellybell]

Not to butt in, but I can confirm what Howard has mentioned - making a new local.mysite folder in the sites folder, and duping my local site settings there. I learned it from DAMP, actually, because DAMP can be configured to do it that way, and it's what always worked best for me. I always wished they had an auto-symlink function that linked back your sites/default/files folder from this sites/local.mysite folder, so I didn't have to do it manually. But either way, this sites/local (with a gitignore for the folder/*) is the only system I ever have figured out that works and avoids dealing with the round-robin permissions hassle.

Kelly Bell
[email protected]
917-446-1555