Modify NativeFileSessionHandler to avoid open_basedir issue with default session path #2598
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hit the same snag with open_basedir restrictions as described in issue #2579. The trouble is with the Symfony session file storage handler checking the existence of the session path.
This is useful when a website has its own session path, but in many distributions the default session path is shared over the entire server (e.g. /var/lib/php5 in Debian, which also has its own garbage collection implementation tied in with that).
Complementing open_basedir restrictions make sure that runtime code is unable to read session data, as it has no business there from a security perspective. Turning off open_basedir restrictions on such a path will make any session data unnecessary vulnerable to things like remote file inclusion.
Also, in such a situation it is safe to assume the session path always exists, making checking it unnecessary as usually file system permissions prohibit creating a new directory in that location anyway.
This patch modifies the Symfony NativeFileSessionHandler by adding a little exception handling, which takes care of the open_basedir restriction only when the default session path is used. When a session path is specified through config the developer is responsible for making sure that it is within restrictions.