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

go to bug id or search bugs for

Request #66462 Add opcache.api_enabled to provide password-based access to API functions
Submitted: 2014-01-10 23:37 UTC Modified: 2015-04-06 20:47 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: Terry at ellisons dot org dot uk Assigned: dmitry (profile)
Status: Wont fix Package: opcache
PHP Version: master-Git-2014-01-10 (Git) OS: N/A
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: Terry at ellisons dot org dot uk
New email:
PHP Version: OS:

 

 [2014-01-10 23:37 UTC] Terry at ellisons dot org dot uk 
Description:
------------
As per README addition:

opcache.api_password (default "")
    calling OPcache API functions only from PHP scripts which first
    the API by calling opcache_enable_api("password"). This parameter
    is set to the MD5 of the required password.  Note that if the 
    opcache.restrict_api is also set then both tests are applied. 

The patch is attached

Test script:
---------------
This PHPT validates the functionality:

--TEST--
Validate use of the directive
--INI--
opcache.enable=1
opcache.enable_cli=1
opcache.api_password="e946adb45d4299def2071880d30136d4"
--SKIPIF--
<?php require_once('skipif.inc'); ?>
--FILE--
<?php
var_dump(opcache_get_status());
var_dump(opcache_enable_api("fred"));
var_dump(opcache_get_status());
var_dump(opcache_enable_api("Mary had a little lamb"));
$status = opcache_get_status();
echo "Get status ", (is_array($status) && isset($status['scripts'][__FILE__])) ? "works":"fails", "\n";
?>
--EXPECTF--
Warning: Zend OPcache API is restricted by "api_password" configuration directive in %s on line 2
bool(false)

Warning: Zend OPcache Invalid API enable password in %s line 3
bool(false)

Warning: Zend OPcache API is restricted by "api_password" configuration directive in %s on line 4
bool(false)
bool(true)
Get status works

Patches

Opcache-password.patch (last revision 2014-01-10 23:38 UTC by Terry at ellisons dot org dot uk)

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-01-11 06:29 UTC] krakjoe@php.net 
-1

This is a horrible hack and not required, should you need to secure access to a script utilizing status functions of opcache then you should do that in the industry standard way, we should not provide a half baked hack and shout out "we got this" when we haven't, at all ...
 [2014-01-11 12:50 UTC] Terry at ellisons dot org dot uk 
Joe,

The requirement that I am trying to address here is a simply one: a set off apps is being developed by various teams of application developers, plus imported 3rd party libraries/applications and run an a production system controlled by sysadmins within a separate subgroup with in the same corporate or organisational domain.  The sysadmins will want to have some simple assurance mechanism to prevent app developers putting in, say development-specific, opcache calls which could then trash the production system performance if executed.  

Yes, the opcache.restrict_api parameter already enables sysadmins to limit access to the Opcache API according to the translated path of the request API and therefore configure the webserver's access control mechanisms to enable effective access control over the opcache API.  But this is not well understood by the sysadmin community.  We are left with a requirements interpretation as to whether SysAdmins would prefer having a password-based alternative.  I have previously discussed this with Dmitry offlist before developing the patch, and as I said it was up to him whether this would be viewed as useful and worth committing.

As the value judgement "this is horrible hack...", this is essentially the same approach as adopted by packages such as MySQL, MediaWiki and phpBB for basic password access.  If we are to offer a password based alternative, then (because of the need to avoid platform and build dependencies) we need to limit ourselves to ext/standard exported functions. MD5 is currently the only such hash implemented by ext/standard that has an exported API, so don't have easy access to alternatives such as SHA-512.
 [2014-01-13 10:20 UTC] dmitry@php.net
-Status: Open +Status: Assigned -Assigned To: +Assigned To: dmitry
 [2015-04-06 20:47 UTC] dmitry@php.net
-Status: Assigned +Status: Wont fix
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Thu Nov 06 00:00:02 2025 UTC