Permissions issue when clearing cache

[alsciende]

Since I installed Exercise/HTMLPurifierBundle, I have an error every time I clear the cache on my Symfony server:

[Symfony\Component\Filesystem\Exception\IOException]
Failed to remove file "/var/www/nrdb/app/cache/prod_old/htmlpurifier/URI/4.6.0,8d03c8ec0e84e7feb92afd4c0f1735841b5fdacf,1.ser".

And indeed, the directory app/cache/prod/htmlpurifier/HTML is owned by www-data with permission 755, so my user cannot delete the files in it.

I applied the setfacl commands to set up the permissions in app/cache and app/log, but that doesn't seem to do the trick.

$ ls -la app/cache/prod
total 656
drwxrwxr-x+  11 alsciende www-data   4096 Jan 26 03:43 .
drwxrwxr-x+   5 www-data  www-data   4096 Jan 26 03:43 ..
drwxrwxr-x+   2 alsciende www-data   4096 Jan 26 03:45 annotations
-rw-rw-r--+   1 alsciende www-data 194989 Jan 26 03:43 appProdProjectContainer.php
-rw-rw-r--+   1 alsciende www-data  70159 Jan 26 03:43 appProdUrlGenerator.php
-rw-rw-r--+   1 alsciende www-data  79081 Jan 26 03:43 appProdUrlMatcher.php
drwxrwxr-x+   3 alsciende www-data   4096 Jan 26 03:43 assetic
-rw-rw-r--+   1 alsciende www-data   4904 Jan 26 03:43 classes.map
-rw-r--r--+   1 www-data  www-data 189453 Jan 26 03:43 classes.php
drwxrwxr-x+   3 alsciende www-data   4096 Jan 26 03:42 doctrine
drwxrwxr-x+   2 www-data  www-data   4096 Jan 26 03:43 fosJsRouting
drwxrwxr-x+   3 alsciende www-data   4096 Jan 26 03:45 htmlpurifier
drwxrwxr-x+   4 www-data  www-data   4096 Jan 26 03:43 http_cache
drwxrwxr-x+   2 alsciende www-data   4096 Jan 26 03:45 sessions
-rw-r--r--+   1 alsciende www-data  27882 Jan 26 03:43 templates.php
drwxrwxr-x+   2 www-data  www-data   4096 Jan 26 03:43 translations
drwxrwxr-x+ 105 alsciende www-data   4096 Jan 26 03:43 twig
$ ls -la app/cache/prod/htmlpurifier/
total 24
drwxrwxr-x+  3 alsciende www-data 4096 Jan 26 03:45 .
drwxrwxr-x+ 11 alsciende www-data 4096 Jan 26 03:43 ..
drwxr-xr-x+  2 www-data  www-data 4096 Jan 26 03:45 HTML

[JeremieSamson]

Same here, any update ?

[adfinlay]

I too have encountered this issue, I've already checked my acl settings

[ediblemanager]

Facing the same, so had to disable the purifier and implement another interim solution. A fix would be greatly appreciated!

[MasterB]

+1

My workaround:
Use a separate directory outside ../cache/dev and ../cache/prod

#config.yml
exercise_html_purifier:
default:
Cache.SerializerPath: "%kernel.root_dir%/cache/htmlpurifier"

[Richard87]

Hi!
I also have the same problem, running version
exercise/htmlpurifier-bundle dev-master 3b5842d: (Symfony 3)

CLI user is different then apache user, but the user is also in the apache group...

Folders look like this:

[eportal@vps htmlpurifier]$ ll
total 12
dr----x--t 2 apache apache 4096 Feb 20 16:03 CSS
dr----x--t 2 apache apache 4096 Feb 20 16:03 HTML
dr----x--t 2 apache apache 4096 Feb 20 16:03 URI

And my settings:

exercise_html_purifier:
    default:
       Cache.SerializerPath: '%kernel.cache_dir%/htmlpurifier'
       Cache.SerializerPermissions: 777

NOTE
The workaround does work: '%kernel.root_dir%/../cache/htmlpurifier'

[spolischook]

@Richard87 There are many documentation about permissions on Symonfy2
http://symfony.com/doc/current/book/installation.html#checking-symfony-application-configuration-and-setup
Read Setting up Permissions block.

[Richard87]

Hi, thanks for your response @spolischook , I have read those, and everything else is working flawless, its just HTML Purifier that has problems...

[spolischook]

@Richard87 did you can find piece of code that produce that error?

[alister]

The issue is that the SerializerCacheWarmer in the bundle only creates the directory within the Symfony cache when a site is deployed.

A @Richard87 says, the subdirectories and files within that directory are only created when the main HTMLPurifier code is run, and so they are created as the webserver user, not as the deployment user that runs the initial warmup. This means that the same user that deploys the code probably does not have access to delete the files later.

Having the bundle's SerializerCacheWarmer also run code that produces the (all the possible) subdirectories for the serialised files would, very likely, solve the issues.

[spolischook]

@alister maybe create all possible subdirectories will solve the issue.
Any way I need to have some code to see that can resolve the issue.

[alister]

The problem of the files being generated by HTMLPurifier in its initial run (by the web-user) would still remain. I've tried to find a simple 'build cache' function within the library - without luck. So, I'm taking a more 'brute force' approach - running purify() within the warmer.

Since a Cache Warmer can take a service as an argument, I'm adding in in there:

<service id="exercise_html_purifier.cache_warmer.serializer" class="%exercise_html_purifier.cache_warmer.serializer.class%">
  <argument>%exercise_html_purifier.cache_warmer.serializer.paths%</argument>
  <argument type="service" id="exercise_html_purifier.default" />
  <tag name="kernel.cache_warmer" />
</service>

And the PHP:

SerializerCacheWarmer::__construct(array $paths, HTMLPurifier $htmlPurifier);
    $this->htmlPurifier = $htmlPurifier;

To build the caches [HTML, CSS, URI] within the warmer, run the purify() function with enough content to need to build all of the definitions:

$this->htmlPurifier->purify('<div style="border: thick">-2</div>');
$this->htmlPurifier->purify('<div style="background:url(\'http://www.example.com/x.gif\');">');

These create the seriali[zs]ed files at the same time, and with the same user as the rest of the symfony cache.

The warmup() function can take multiple directories, but currently, this code only passes in a single service ("@exercise_html_purifier.default"), which would probably not be enough to handle more than one path being setup.

All of the code/config to fix this issue is above, I'm happy to make that into a PR if you want - but I believe it would solve the 95+% case of the files being created with the web-user, and not the deployment user (causing problems on attempted deletion).

[alister]

Are there any thoughts on my PR:37?