ext/sessions/mod_files.c:281 has a hardcoded openbasedir-check
skipping of "/tmp" path for storing session-files, if
sessions.save_path is not manually set.
This leads to the failure of session_save_path_variation5 test on mac
os x, as default temporary path here is "/var/tmp" and not "/tmp"
Anyway, this looks like something done wrong from the beginning.
Shouldn't "/tmp" be explicitly added to open_basedir list? Why should
it have any special meaning?
I propose to remove special treatment of "/tmp" (should be mentioned
in upgrade-docs)
Other option would be to skip check for any path, which is returned by
php_get_temporary_directory() call, but that sounds like a very bad
idea.
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
well, in case there are no objections I will remove special treatment
of "/tmp" path in sessions code of 5.3 and 6.0
should 5.2 also be "fixed"?
ext/sessions/mod_files.c:281 has a hardcoded openbasedir-check
skipping of "/tmp" path for storing session-files, if
sessions.save_path is not manually set.This leads to the failure of session_save_path_variation5 test on mac
os x, as default temporary path here is "/var/tmp" and not "/tmp"Anyway, this looks like something done wrong from the beginning.
Shouldn't "/tmp" be explicitly added to open_basedir list? Why should
it have any special meaning?
I propose to remove special treatment of "/tmp" (should be mentioned
in upgrade-docs)Other option would be to skip check for any path, which is returned by
php_get_temporary_directory() call, but that sounds like a very bad
idea.--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
well, in case there are no objections I will remove special treatment
of "/tmp" path in sessions code of 5.3 and 6.0
should 5.2 also be "fixed"?
i would not put this into 5.2 this late into the lifetime of this branch.
regards,
Lukas
Hi!
ext/sessions/mod_files.c:281 has a hardcoded openbasedir-check
skipping of "/tmp" path for storing session-files, if
sessions.save_path is not manually set.
I would think the idea was to make it easier on inexperienced users.
Since default AFAIK is /tmp, and it is highly unlikely that somebody
would need to hide /tmp from the users, it makes more scenarios to work
out of the box.
Anyway, this looks like something done wrong from the beginning.
Shouldn't "/tmp" be explicitly added to open_basedir list? Why should
it have any special meaning?
I propose to remove special treatment of "/tmp" (should be mentioned
in upgrade-docs)
Is there any problem that this treatment is causing? I.e. on Mac the
default is different, but that's not a problem of this treatment - it's
rather missing special treatment of /var/tmp on mac, I'd say :) So Mac
users don't get this boon, but is it the reason to remove it form other
users?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
ext/sessions/mod_files.c:281 has a hardcoded openbasedir-check
skipping of "/tmp" path for storing session-files, if
sessions.save_path is not manually set.I would think the idea was to make it easier on inexperienced users. Since
default AFAIK is /tmp, and it is highly unlikely that somebody would need to
hide /tmp from the users, it makes more scenarios to work out of the box.Anyway, this looks like something done wrong from the beginning.
Shouldn't "/tmp" be explicitly added to open_basedir list? Why should
it have any special meaning?
I propose to remove special treatment of "/tmp" (should be mentioned
in upgrade-docs)Is there any problem that this treatment is causing? I.e. on Mac the default
is different, but that's not a problem of this treatment - it's rather
missing special treatment of /var/tmp on mac, I'd say :) So Mac users don't
get this boon, but is it the reason to remove it form other users?
Yes, it is in my opinion a flaw. It is the admin role to define a
correct open_basedir set. Temporary directory should not be system
wide in a shared hosting environment, especially not when the session
are stored there by default. I don't think we should fix documentation
problems by adding such tricks in a security related feature :)
Cheers,
Hi!
ext/sessions/mod_files.c:281 has a hardcoded openbasedir-check
skipping of "/tmp" path for storing session-files, if
sessions.save_path is not manually set.I would think the idea was to make it easier on inexperienced users. Since
default AFAIK is /tmp, and it is highly unlikely that somebody would need to
hide /tmp from the users, it makes more scenarios to work out of the box.Anyway, this looks like something done wrong from the beginning.
Shouldn't "/tmp" be explicitly added to open_basedir list? Why should
it have any special meaning?
I propose to remove special treatment of "/tmp" (should be mentioned
in upgrade-docs)Is there any problem that this treatment is causing? I.e. on Mac the default
is different, but that's not a problem of this treatment - it's rather
missing special treatment of /var/tmp on mac, I'd say :) So Mac users don't
get this boon, but is it the reason to remove it form other users?
The proper way is to explicitly specify "/tmp" in open_basedir, and,
actually, there is quite a common practice of doing so.
This "feature" we have was never documented.
It was introduced in 5.2.2, so it wasn't there "forever"
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/