ZF-1429: Zend_Search_Lucene needs something to manage index security


Index files are created with default permissions now.

It looks like 660 mode is the best for default permissions (from safety point of view).

From the other side it should be index class property and there should be an API to change it.


Hi, I have patched the File/Filesystem.php file, allowing it to chmod the file it opens, when it is possible. It's working on my local box, but that's because I have manually forced me.apache as in that directory. The me user launches the indexing proces as a batch script, while apache accesses it for searching. The patch makes ALL files under the chosen index path 0660, and maybe that's wrong, I am not that expert on this. I think it's pretty unharmful, after all. :)

Could you chek it up? Do you think it can work, or is it not generic enough?

Index: library/Zend/Search/Lucene/Storage/File/Filesystem.php

--- library/Zend/Search/Lucene/Storage/File/Filesystem.php (revision 5828) +++ library/Zend/Search/Lucene/Storage/File/Filesystem.php (working copy) @@ -61,6 +61,8 @@ if ($this->_fileHandle === false) { ini_set('track_errors', $trackErrors); throw new Zend_Search_Lucene_Exception($php_errormsg); + } else { + if (fileowner($filename) == posix_geteuid()) chmod($filename, 0660); }

     ini_set('track_errors', $trackErrors);


Zend_Search_Lucene_Storage_Directory_Filesystem::setDefaultFilePermissions() and Zend_Search_Lucene_Storage_Directory_Filesystem::getetDefaultFilePermissions() methods may be used to manage files permissions.

Updating Fix Version to follow issue tracker conventions.

Please reconsider your thoughts on forcing the use of chmod.

In restrictive environments it is completely valid that a non-owner of the lucene index files has proper write permissions to write but still is not owner. And, as you're ware, chmod can only be issued by the owner of the files. Group ownership is not considered.

I would strongly advice to remove this patch in its entirety. Zend_Search_Lucene should not deal with permission in anyway itself. This should be left to the environment it is running in, and especially under Unix systems this is easily done by making sure the proper umask is set.

If this is not an option, please at least consider the ability to disable the call to chmod().

Here is an example scenario of mine: The index is created from a non www-data user. When I do this and access the index from within the web, I get

Error: chmod(): Operation not permitted in includes/Zend/Search/Lucene/Storage/Directory/Filesystem.php on line 189

0 includes/Zend/Search/Lucene/LockManager.php(85): Zend_Search_Lucene_Storage_Directory_Filesystem->createFile('read.lock.file')

1 includes/Zend/Search/Lucene.php(410): Zend_Search_Lucene_LockManager::obtainReadLock(Object(Zend_Search_Lucene_Storage_Directory_Filesystem))

2 includes/App/Search.php(252): Zend_Search_Lucene->__construct('/var/www/netcar...')

3 http/suche/index2.php(59): App_Search->search('milbe', 0)

4 {main}

However, there's actually no technical reason why a chmod() call is needed here. The permissions are completely fine as they're and it should not concern the web application that it is not the owner of some of the files. Still the write permissions to create the file are there.


We are on 1.0.2 and this is causing us all kinds of problems for exactly the same reasons Markus mentions.

There's no need to mess with the permissions I (a reasonably skilled admin) places on files. Because my apache process runs under a restricted user, searching needs to be able to read files created by another user (one who has proper access to writing those files).

As it stands we need to jump through many hoops to have this work at all.

This is also the case in version 1.0.4.

Re-opening as new bug: ZF-2779

Reopened issue [ZF-2779] is fixed.