php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #60411 Session Error When Browsing Between Secure and Non-Secure Subdirectories
Submitted: 2011-11-29 18:42 UTC Modified: 2012-03-31 04:07 UTC
From: jgalvin at bnl dot gov Assigned:
Status: Wont fix Package: Session related
PHP Version: 5.3.8 OS: Windows Server 2003 - IIS 6
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: jgalvin at bnl dot gov
New email:
PHP Version: OS:

 

 [2011-11-29 18:42 UTC] jgalvin at bnl dot gov 
Description:
------------
Configuration: Windows Server 2003 SP2 + IIS 6.0 + PHP 5.3.8 + FastCGI 1.5 (We have session.auto_start set to true in our php.ini file.)

When a user browses to a secure application, let's call it "Application A," which can either be under SSL or just have anonymous access turned off through IIS and therefore requires authentication, then browses to another application, we'll call "Application B," that does not require authentication, PHP throws the following error:

Error: [2] Unknown: open(D:\PHP\Session\\sess_9ksat3tm0nk8lbfcfgk3pp99o0, O_RDWR) failed: Permission denied (13) File: http://www.mysite.com/mypage.php Line: 0 Error: [2] Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (D:\PHP\Session\) File: http://www.mysite.com/mypage.php Line: 0

The reverse scenario also results in the error -- if the user browses to Application B (no authentication) and then to Application A (which requires authentication).

I was able to prevent the error from occurring by turning anonymous access off in Application B, which forces the user to authenticate when accessing Application B. However, this is not a viable solution because we have to allow users to access public web applications without forcing them to authenticate.

So, simply put: How can we allow users to browse between secure sites and public sites knowing that PHP wants to read/write to the same session data file across these various sites, which causes the error as soon as the user goes from a secure site to a public site or vice versa?

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-11-30 00:10 UTC] yohgaki@php.net
-Status: Open +Status: Feedback
 [2011-11-30 00:10 UTC] yohgaki@php.net 
Are you running FastCGI with different privileges for application 
A and B?

Then you would end up with access error for session data files.

Try to run FastCGI with the same privilege or set different save 
dir for app A and B. (Or use memcache or any other db based session 
data storage)
 [2011-12-06 14:15 UTC] jgalvin at bnl dot gov
-Status: Feedback +Status: Open
 [2011-12-06 14:15 UTC] jgalvin at bnl dot gov 
Thank you very much for your helpful advice, yohgaki.

UPDATE:  After giving the Internet Guest Account (IUSER_MACHINENAME) the following permissions on the folder where the session files are stored, the error no longer occurred when going from a "secure" site requiring authentication to a "public" site that does not require authenticaiton.

Permissions:

- List Folder / read Data
- Read Attributes
- Read Extended Attributes
- Create Files / Write Data
- Create Folders / Append Data
- Write Attributes
- Write Extended Attributes

However, the error was still occurring when browsing sites in the opposite direction -- going from a "public" site that does not require authenticaiton to a "secure" site that does require authentication.

By adding the "Authenticated Users" account to the session folder (with the same permissions listed above), the error no longer occurs.

So, the problem appears to be resolved.  However, since I do not have any experience with server administration, I am not entirely sure that the solution described above is appropriate and won't introduce any additional volunerabilities by giving these two additional users permission on the session folder.  Any thoughts?
 [2012-03-31 04:07 UTC] yohgaki@php.net
-Status: Open +Status: Wont fix
 [2012-03-31 04:07 UTC] yohgaki@php.net 
You need to privilege to access files. "Authenticated Users" may work for you.

Note that any authenticated users may create/read/delete/modify session files. 
For most servers, it would be ok, but depends on your environment, usage and 
security requirement.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Apr 25 09:01:29 2024 UTC