Page MenuHomePhabricator

PhabricatorPHPPreflightSetupCheck can raise a nonfatal `open_basedir` exception which presents the user with a nonfunctional "ignore" action
Closed, ResolvedPublic

Description

Hello,

Here's a new bug report, somewhat related to T11613, where I have posted the server versions, settings and so on.

To recap:

PHP Version 5.5.9-1ubuntu4.19
Linux 3.13.0-45-generic #74-Ubuntu SMP 64 bit (Ubuntu LTS 14.04)
Apache/2.4.7 (Ubuntu)

Phabricator rP1ee426e4ac82c7afcf0bb7a33327870f0d7f78a9 (git clone has been performed today).
arcanist 9e82ef979e8148c43b9b8439025d505b1219e213 (25 Aug 2016)
libphutil 0107c187b6d8a4c1725972ab80a6cdc97d9912d3 (9 Sep 2016)

Reproduction steps:

  • Follow the guide
  • Go to the new install website
  • Have PHP with open_basedir, therefore setup is going to warn you about disabling it
  • Press the: "Ignore Setup Issue" link

2016-09-12 20_15_49-Phabricator Setup Error.png (607×768 px, 29 KB)

Expected result:

Setup wizard going on to next step, ignoring the warning.

Actual result:

This URL gets called and I see the browser showing the "page loading" visual indication:

http://subdomain.domain.tld/config/ignore/php.open_basedir/

However nothing else happens. The same page appears again.

I can spam "Ignore..." and it still brings the wizard back to the same step.

Event Timeline

This is unique to this particular setup check (open_basedir configured, but not in a way that creates a concrete problem we're able to detect).

I'm inclined to just simplify this check and make any value for open_basedir cause a fatal setup error.

epriestley renamed this task from Pressing "Ignore Setup Issue" during setup won't actually cause setup to ignore the issue. to PhabricatorPHPPreflightSetupCheck can raise a nonfatal `open_basedir` exception which presents the user with a nonfunctional "ignore" action.Sep 12 2016, 8:07 PM

This is unique to this particular setup check (open_basedir configured, but not in a way that creates a concrete problem we're able to detect).

I'm inclined to just simplify this check and make any value for open_basedir cause a fatal setup error.

I am not sure restricting Phabricator so much is beneficial to the users. Even if I am using my own VPS, nowadays most server administration tasks can be greatly automated by applications / panels like ISPConfig... Those automation software, however, impose certain security measures (they are born with multi-customer security in mind) like apparmor, open_basedir etc.

If the very fact of having open_basedir per se is not fatal, it should not be blanket forbidden to have it.

In fact, very wisely, Phabricators says: "Although this setting appears permissive enough...." and "Consider disabling 'open_basedir'.", suggests open_basedir is not something utterly devastating.

I think the current philosophy is perfect, no need to restrict it further.

I like the "I warn you this could cause issues, go on at your peril" approach, because this gives ways to keep open_basedir while setting it up to have it compatible with Phabricator.

Features unfortunately aren't free. They cost time to build, test, and provide lifetime support of, that we must pay.

In T11627#194460, @chad wrote:

Features unfortunately aren't free. They cost time to build, test, and provide lifetime support of, that we must pay.

That'd would be totally true hadn't support for the situation been there yet. But AFAIK somebody already paid to code in the check, the warning and so on. What's left to pay, to consider the warning as a... warning (that is, a non blocking step) and let the guy go ahead?

Providing support isn't free.

Generally, it's always cheaper for us to code checks defensively per our time. That lightens support which then allows for time for building features. We're just two developers here and we don't get a paycheck for our time or support we offer. Maybe someday :)