Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40114
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 66.249.92.169 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=nFNlK7P70nLAkmHlY+vI3yyIQuiU3BFaerJU8A/t98NNKOuG+oplslAuO7amGMCBf7
         LAfT6v4521bO2pfhFiNrO7qkOxKcivnLdwtol1xY1hK1JoAdUH+GSIiXS0VtjaZH3WvH
         p5UlxpaTWxANXD6rsUgDLeeXpd9Pv2IYaGU6s=
Message-ID: <fe05d1540808271502r40e88979i4c5a48809be912cd@mail.gmail.com>
Date: Thu, 28 Aug 2008 00:02:25 +0200
To: "Stanislav Malyshev" <stas@zend.com>
Cc: "Alexey Zakhlestin" <indeyets@gmail.com>, 
	"PHP Internals" <internals@lists.php.net>
In-Reply-To: <48B5CE4A.7000807@zend.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <cd5680a20808270130g5acab941uf9c3e8cc2f66f458@mail.gmail.com>
	 <48B5CE4A.7000807@zend.com>
Subject: Re: [PHP-DEV] open_basedir + sessions bug (or a feature?)
From: pierre.php@gmail.com ("Pierre Joye")

On Wed, Aug 27, 2008 at 11:59 PM, Stanislav Malyshev <stas@zend.com> wrote:
> 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,
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org