Writing to /usr/share/httpd/.config/psysh is not allowed

[gdpa]

trafficstars

I'm getting this error:

Writing to /usr/share/httpd/.config/psysh is not allowed.

on linux with apache installed.

[95jonpet]

The user that appache/php-fpm runs under must have the required read/write access to the mentioned file. This user is not always the same as the user that you are using to connect with. Try altering the permissions for a www-data user if one exists.

chown www-data:www-data /usr/share/httpd/.config/psysh
chmod u+w /usr/share/httpd/.config/psysh

[gdpa]

There is no .config directory on the path. Why it doesn't use local laravel project directory for saving psysh file?

[95jonpet]

That is the issue then. It tries to create a new file/directory (write permission required) in a folder where write permissions are not held.

[bernhardh]

You can modify the location by setting the following to your .env

XDG_CONFIG_HOME=/path/to/new/location

best regards

[ragingdave]

This appears to be broken now with the release of Laravel 5.8 and phpdotenv 3. The $_ENV is populated correctly, but the old behavior of phpdotenv put the .env variables into a place where getenv() had access to them, now .env variables no longer make it there and this fix is now broken. Not sure if it's something to fix here, but I feel like I stumbled across a fairly large breaking change.

[GrahamCampbell]

Instead of using getenv, use Laravel's env function. It is threadsafe, unlike PHP's getenv function.

[GrahamCampbell]

NB The env function has existed since Laravel 5.4 and is the recommended way to access environment variables when needed. Finally, in Laravel 5.8, the long-standing issue of the thread-safety has been fixed. That is, if someone forgets to use cached config in production, and there are other sites running, then secrets may be leaked to the other sites. Laravel 5.8 is no longer vulnerable to this, and I'd be strongly against changing the framework defaults back to populating using putenv also.

[ragingdave]

This doesn't appear to be something that we can control as the usage is in Xdg, so I don't believe this can even be fixed since that (I would assume) is not only used in laravel apps.

Specifically https://github.com/dnoegel/php-xdg-base-dir/blob/master/src/Xdg.php Which is the failing code (aka broken) as a result of this change, and shouldn't really have to adhere to ONLY the laravel ecosystem. I love laravel, but it's not the only framework out there that might be using some sort of REPL environment. I understand the change from a security perspective, but I'm just confused as to both how to address this (I would argue) breaking change. As a result, this package basically ends up being dead in the water....and it was a REALLY useful package.

[GrahamCampbell]

You can still recover the old behaviour of Laravel 5.7 if you need it, in 5.8, by using your own bootstrapper. Just define the following class in your app:

<?php namespace App\Foundation;

use Dotenv\Dotenv;
use Illuminate\Foundation\Bootstrap\LoadEnvironmentVariables as BaseLoadEnvironmentVariables;

class LoadEnvironmentVariables extends BaseLoadEnvironmentVariables
{
    /**
     * Create a Dotenv instance.
     *
     * @param  \Illuminate\Contracts\Foundation\Application  $app
     * @return \Dotenv\Dotenv
     */
    protected function createDotenv($app)
    {
        return Dotenv::create($app->environmentPath(), $app->environmentFile());
    }
}

And then in your console and http kernel files in your app, overwrite the bootstrappers property, replacing \Illuminate\Foundation\Bootstrap\LoadEnvironmentVariables::class, with \App\Foundation\LoadEnvironmentVariables::class,.

[bsormagec]

XDG_CONFIG_HOME=/tmp working on vapor @gdpa