Actually:
This is due to each site using the same set of cookies (more
importantly, the PHPSESSIONID cookie).
Example:
User A creates a random session with the file owned under /var/lib/php
with the user id of that site and saves the newly generated session ID
in the cookie.
User B tries to initiate a PHP session, sees that cookie, and tries
using the session file it points to, only to discover it is owned by the
user for Site A. This is due to them sharing the same cookie-namespace
because you're accessing the sites through the same HTTP_HOST
You can get around this by:
- Having each user use a separate session_name() (kind of tedious)
- Using URL's to pass the session id between script page requests
(doesn't look that pretty)
- Use the session_set_cookie_params() function to set the allowed path
for the session cookie for each user to '~/username' so the cookies PHP
sessions use won't overlap between the users. (probably the best option
here)
On 03/29/2012 01:00 PM, Daniel Llewellyn wrote:
On 29 Mar 2012, at 17:45, [email protected] wrote:
My problem: All php-Apps that create sessions get in conflict because all the
php-instances (runing as different users) seem to generate the SAME session-ids
which leads into identical session-file-names in /var/lib/php/sessions/. The
first php-app (or php-instance) successfully creates its session-file, but all
following apps (instances) end up with errors like …
are you sure?
Warning: session_start(): open(/var/lib/php/session/sess_XXXXXX, O_RDWR)
failed: Permission denied (13) in /home/xxx/home/public_html/index.php on line X
Warning: Unknown: open(/var/lib/php/session/sess_XXXXXX, O_RDWR) failed:
Permission denied (13) in Unknown on line 0
Warning: Unknown: Failed to write session data (files). Please verify that the
current setting of session.save_path is correct (/var/lib/php/session) in
Unknown on line 0
that looks suspiciously like a permissions error on the directory
/var/lib/php/session, NOT an ownership error on
/var/lib/php/session/sess_12345. Are you sure your users are able to create
files in this directory?
Currently I have<Location>-Blocks that configure for each user_dir its own
php.ini (with suPHP_ConfigPath) in which i define different sessions-folders for each
app/user. That works but is an ugly workaround.
How do you fix/prevent/solve that? I was really surprised no one had that issue
before. There MUST be a better way.
That's because it only matters who has read permission on a session file when
php tries to instantiate that particular session id. Normally php sessions will
create random id unless it is informed of a previously active session via the
appropriate cookie or query string variable. Thus, running php under multiple
accounts will also retain the randomness thereby preventing conflicts of id.
And little offtopic: How would force php/apache, running as its own user
(apache, www-data, depending on the OS), to set the rights of newly created
files always to 775 instead of 755 (which seems default)?
google-foo: umask
_______________________________________________
suPHP mailing list
[email protected]
https://lists.marsching.com/mailman/listinfo/suphp
_______________________________________________
suPHP mailing list
[email protected]
https://lists.marsching.com/mailman/listinfo/suphp
