[CPANEL-23314] CSF Suspicious File Alerts (/tmp/pma_template_compiles) after V76 Update
Suspicious File Alert
File: /tmp/pma_template_compiles_cpanelaccount/twig/xx/largenumbersandlettersfilename.phpThis alerts started to appear after v76 update apparently in random times, i first see it on a new server that i deployed past week, then i started to receive this alerts from my other servers that i updated to v76 The path is almost always the same, the only thing that changes is the cpanelaccount, the folder after pma_template_compiles_cpanelaccount and the php filename Im not looking a way or some response about how to disable CSF/LFD alerts, i want to know if v76 has a new behavior with php files or what is causing the creation of this files on server
-
Hello Everyone, Internal case CPANEL-23314 is open to address an issue in cPanel & WHM version 76 where accessing phpMyAdmin as a cPanel user leads to the creation of pma_template_compiles_$user files in the system's /tmp directory. While this doesn't lead to any direct issues with cPanel & WHM itself, it's contrary to the behavior seen in applications such as Horde and Roundcube where temporary files are stored in the /home/$user/tmp/ directory. This can lead to false positives from applications such as CSF that monitor the system's /tmp directory for suspicious files. I'll monitor this case and update this thread with more information on it's status as it becomes available. In the meantime, anyone receiving these alerts from CSF can read the following section from the 0 -
Oh! Excellent :) Does we have eta for this? receive dozens of alerts per hour per server for this issue a is bit annoying 0 -
Does we have eta for this? receive dozens of alerts per hour per server for this issue a is bit annoying
Hi @tui, Update 11/06/2018: This is fixed in cPanel & WHM version 76.0.5 (tentatively planned for publication to the CURRENT tier on 11-07-2018 and to the RELEASE tier on 11-08-2018). Thank you.0 -
You may be able to stop the emails from CSF until the cPanel fix is published by adding a down-and-dirty regex to the /etc/csf/csf.fignore file Something like: /tmp\/pma_template_compiles_*0 -
Hello Everyone, To update, this is fixed in cPanel & WHM version here. Thank you. 0 -
Great news, thanks! 0 -
Digging up this 5 year old thread because this phenomenon still exists. Since I've had it ignored in CSF for years, the only reason I noticed is because I've been in the process of testing some new (cPanel 116.0.11, CloudLinux 8.9.0, phpMyAdmin 5.2.1) servers and checking log files, and sure enough:
This is from an account that I migrated from an old server to the new one, and I was surprised to see that phpMyAdmin sessions are still generating these files to that location.
While we know it's not affecting cPanel function, it does generate a lot of files / folders. I see them going back to February 2019, not long after the OP started this thread in late 2018.
So, was it ever really fixed?
0 -
cPRex - do you happen to know anything about this?
0 -
Here's the rest of that sentence that got chopped off from the old Forum:
"I want to point out that while this is fixed for new phpMyAdmin sessions in cPanel & WHM version 76.0.5, the existing /tmp/pma_template_compiles_resources* files/directories are not automatically removed after the update. The existing files/directories will need to be manually removed from the system's /tmp directory after the update to avoid additional notifications from CSF.
The compile files are now stored at /var/cpanel/userhomes/cpanelphpmyadmin/tmp for root phpMyAdmin sessions, and /home/$USER/tmp when cPanel users access phpMyAdmin."
The case was fixed in 76.0.5. If you access PHPMyAdmin as the cPanel user, are you still seeing new session files created in that directory with today's date?0 -
Thank you cPRex
I think I might be overlooking something.
Is it safe to delete
the /pma_template_compiles_$userfolder completely from each account's /home/$user/tmp folder?If so, what would be the best approach to doing that globally?
Maybe something like rm -rf /home/*/tmp/pma_template_compiles_*
Or is there a better / safe method?
Thanks for your help!
0 -
Running rm directly with wildcards always makes me nervous. I'd feel better/safer doing this with find as that would allow you to verify the output before piping it to rm.
How about something like this?
find /home/$USER/tmp/ -type d -name "pma_template_compiles_*"
That would show you the list of directories to be deleted before you perform the actual rm:
find /home/$USER/tmp/ -type d -name "pma_template_compiles_*" | xargs rm -Rf
0 -
Thank you again cPRex
Since doing that for each individual user would be a monumental task, and obviously find /home/$USER/tmp/ -type d -name "pma_template_compiles_*" just returns: find: `/home/root/tmp/': No such file or directory
I used:
find /home/*/tmp/ -type d -name "pma_template_compiles_*"
And that returns hundreds of users on each server with pma_template_compiles_username in their /home/username/tmp/ directory.
And it is all just regular customer accounts, so, I think I would need to use this to get the job done:
find /home/*/tmp/ -type d -name "pma_template_compiles_*" | xargs rm -Rf
I agree the wildcard * maybe isn't the best approach, but I'm not sure how else to do this.
I'll start by just removing the pma_template_compiles_username directory on just a few of my own accounts to test the results.
I really appreciate your opinion and advice on this, so please do let me know your thoughts on this approach.
Thank you!
0 -
Oh, I meant for $user to be a wildcard - sorry about that. But yes, that looks fine to me!
0 -
cPRex thanks for your patience with me and your input.
Even just on the first test, when I removed /home/username/tmp/pma_template_compiles_username on an account, a few minutes later it came back.
Not only did the /tmp/pma_template_compiles_username directory come back, but it came back filled with a bunch of folder / files like this:
And the contents of those 2 example files look like this:
<?php
use Twig\Environment;
use Twig\Error\LoaderError;
use Twig\Error\RuntimeError;
use Twig\Extension\SandboxExtension;
use Twig\Markup;
use Twig\Sandbox\SecurityError;
use Twig\Sandbox\SecurityNotAllowedTagError;
use Twig\Sandbox\SecurityNotAllowedFilterError;
use Twig\Sandbox\SecurityNotAllowedFunctionError;
use Twig\Source;
use Twig\Template;/* select_all.twig */
class __TwigTemplate_6c7d644ddf3fc6e6960db2a01a127b36 extends Template
{
private $source;
private $macros = [];public function __construct(Environment $env)
{
parent::__construct($env);$this->source = $this->getSourceContext();
$this->parent = false;
$this->blocks = [
];
}protected function doDisplay(array $context, array $blocks = [])
{
$macros = $this->macros;
// line 1
echo "<img class=\"selectallarrow\" src=\"";
echo twig_escape_filter($this->env, $this->extensions['PhpMyAdmin\Twig\AssetExtension']->getImagePath((("arrow_" . ($context["text_dir"] ?? null)) . ".png")), "html", null, true);
echo "\"
width=\"38\" height=\"22\" alt=\"";
echo _gettext("With selected:");
// line 2
echo "\">
<input type=\"checkbox\" id=\"";
// line 3
echo twig_escape_filter($this->env, ($context["form_name"] ?? null), "html", null, true);
echo "_checkall\" class=\"checkall_box\"
title=\"";
echo _gettext("Check all");
// line 4
echo "\">
<label for=\"";
// line 5
echo twig_escape_filter($this->env, ($context["form_name"] ?? null), "html", null, true);
echo "_checkall\">";
echo _gettext("Check all");
echo "</label>
<em class=\"with-selected\">";
echo _gettext("With selected:");
// line 6
echo "</em>
";
}public function getTemplateName()
{
return "select_all.twig";
}public function isTraitable()
{
return false;
}public function getDebugInfo()
{
return array ( 61 => 6, 54 => 5, 51 => 4, 46 => 3, 43 => 2, 37 => 1,);
}public function getSourceContext()
{
return new Source("", "select_all.twig", "/usr/local/cpanel/base/3rdparty/phpMyAdmin/templates/select_all.twig");
}
}<?php
use Twig\Environment;
use Twig\Error\LoaderError;
use Twig\Error\RuntimeError;
use Twig\Extension\SandboxExtension;
use Twig\Markup;
use Twig\Sandbox\SecurityError;
use Twig\Sandbox\SecurityNotAllowedTagError;
use Twig\Sandbox\SecurityNotAllowedFilterError;
use Twig\Sandbox\SecurityNotAllowedFunctionError;
use Twig\Source;
use Twig\Template;/* modals/index_dialog_modal.twig */
class __TwigTemplate_b7c71d45e736afc41b33e69c5af1baea extends Template
{
private $source;
private $macros = [];public function __construct(Environment $env)
{
parent::__construct($env);$this->source = $this->getSourceContext();
$this->parent = false;
$this->blocks = [
];
}protected function doDisplay(array $context, array $blocks = [])
{
$macros = $this->macros;
// line 1
echo "<div class=\"modal fade\" id=\"indexDialogModal\" tabindex=\"-1\" aria-labelledby=\"indexDialogModalLabel\" aria-hidden=\"true\">
<div class=\"modal-dialog\">
<div class=\"modal-content\">
<div class=\"modal-header\">
<h5 class=\"modal-title\" id=\"indexDialogModalLabel\">";
echo _gettext("Loading");
// line 5
echo "</h5>
<button type=\"button\" class=\"btn-close\" data-bs-dismiss=\"modal\" aria-label=\"";
echo _gettext("Close");
// line 6
echo "\"></button>
</div>
<div class=\"modal-body\"></div>
<div class=\"modal-footer\">
<button type=\"button\" class=\"btn btn-primary\" id=\"indexDialogModalGoButton\">";
echo _gettext("Go");
// line 10
echo "</button>
<button type=\"button\" class=\"btn btn-secondary\" data-bs-target=\"#indexDialogPreviewModal\" data-bs-toggle=\"modal\">";
echo _gettext("Preview SQL");
// line 11
echo "</button>
<button type=\"button\" class=\"btn btn-secondary\" data-bs-dismiss=\"modal\">";
echo _gettext("Close");
// line 12
echo "</button>
</div>
</div>
</div>
</div>
<div class=\"modal fade\" id=\"indexDialogPreviewModal\" aria-hidden=\"true\" aria-labelledby=\"indexDialogPreviewModalLabel\" tabindex=\"-1\">
<div class=\"modal-dialog\">
<div class=\"modal-content\">
<div class=\"modal-header\">
<h5 class=\"modal-title\" id=\"indexDialogPreviewModalLabel\">";
echo _gettext("Preview SQL");
// line 21
echo "</h5>
<button type=\"button\" class=\"btn-close\" data-bs-dismiss=\"modal\" aria-label=\"";
echo _gettext("Close");
// line 22
echo "\"></button>
</div>
<div class=\"modal-body\">
<div class=\"spinner-border\" role=\"status\">
<span class=\"visually-hidden\">";
echo _gettext("Loading…");
// line 26
echo "</span>
</div>
</div>
<div class=\"modal-footer\">
<button class=\"btn btn-primary\" data-bs-target=\"#indexDialogModal\" data-bs-toggle=\"modal\">";
echo _gettext("Go back");
// line 30
echo "</button>
</div>
</div>
</div>
</div>
";
}public function getTemplateName()
{
return "modals/index_dialog_modal.twig";
}public function isTraitable()
{
return false;
}public function getDebugInfo()
{
return array ( 93 => 30, 86 => 26, 79 => 22, 75 => 21, 63 => 12, 59 => 11, 55 => 10, 48 => 6, 44 => 5, 37 => 1,);
}public function getSourceContext()
{
return new Source("", "modals/index_dialog_modal.twig", "/usr/local/cpanel/base/3rdparty/phpMyAdmin/templates/modals/index_dialog_modal.twig");
}
}0 -
Confirmed - when I remove /home/username/tmp/pma_template_compiles_username directory on an account, as soon as I go to their cPanel > phpMyAdmin and view a database, the directory comes back and has a lot of pma_template_compiles_username/twig/xx/ folders with a lot of pma_template_compiles_username/twig/xx/largenumbersandlettersfilename.php files, all with current / new timestamps.
0 -
I see these files on my own personal machine when I checked a few accounts. Are these causing some type of issue? Are we just not expecting these to exist based off that earlier case? Since that was 5 years ago, it's possible this behavior is just changed.
1 -
I don't think they're causing any issue, other than it seems odd that A.) according to everything I've read this was supposed have been changed many versions ago and B.) even after removing the pma_template_compiles_username directory, all it takes is opening phpMyAdmin once to generate 40 pma_template_compiles_username/twig/xx/ folders each with files in them like described above. Something seems a bit off about that.
0 -
Alright - after re-reading the case carefully, I think this is actually the fixed behavior. The original case was to fix these files from being placed in the *system's* tmp directory:
Hello Everyone, Internal case CPANEL-23314 is open to address an issue in cPanel & WHM version 76 where accessing phpMyAdmin as a cPanel user leads to the creation of pma_template_compiles_$user files in the system's /tmp directory. While this doesn't lead to any direct issues with cPanel & WHM itself, it's contrary to the behavior seen in applications such as Horde and Roundcube where temporary files are stored in the /home/$user/tmp/ directory.
so the fix was actually placing these in /home/user/tmp where you are seeing them now.
1 -
I sincerely apologize for not recognizing that. My only excuse - I've been struggling for months to complete server migrations and it's just been one roadblock after another, every time I turn around I find something on the new servers that either isn't acting as expected or needs adjustments. Also finding PHP error logs in places on the new server where they don't even exist on the production servers, generating concerns over using-up users' iNode limits and storage, etc... so I'm under extreme pressure and very sleep deprived. I'm sorry Rex. We need a face-palm icon here.
At least it wasn't all for nothing - these command suggestions that you provided will come in very handy / helpful in other scenarios:
find /home/$USER/tmp/ -type d -name "pma_template_compiles_*"
find /home/$USER/tmp/ -type d -name "pma_template_compiles_*" | xargs rm -Rf
But perhaps I should just delete all my posts in this thread so as not to create confusion for anyone else?
0 -
No worries - I didn't catch it at first either! And nah, it's fine to leave the posts - it at least confirms that things are working as intended.
1
Please sign in to leave a comment.
Comments
22 comments