PHP-App can't create subdirs and read own, created files: the origin problem changed

[mave-git]

How to post a meaningful bug report

1. Read this whole template first.
2. Determine if you are on the right place:
   • If you were performing an action on the app from the webadmin or the CLI (install, update, backup, restore, change_url...), you are on the right place!
   • Otherwise, the issue may be due to the app itself. Refer to its documentation or repository for help.
   • When in doubt, post here and we will figure it out together.
3. Delete the italic comments as you write over them below, and remove this guide.

---

Describe the bug

Trying using the WBCE CMS. Installing works. But a module needs to write files and creates own subdirs. File writung is okay, creating subdirs not. And: Reading the files gives a 403 forbidden nginx error.

Context

• Hardware: root server with dedicated CPUs (netcup.de)
• YunoHost version: newest
• I have access to my server: Through SSH | through the webadmin
• Are you in a special context or did you perform some particular tweaking on your YunoHost instance?: NO

Steps to reproduce

1. Installing my_webapp on a sub-domain sub.domain.tld or domain.tld (tried both)
2. force an update ---- -F
3. Install WBCE CMS via SFTP/Filezilla

Expected behavior

All files written by SFTP are okay, only problems on files and subdirs (tried) written by the CMS.hown/chmod was checked, everything is my_webapp__X:www-data and/or 0644/755.

Logs

;-( PHP-Log shows no error, when it happens.

Short: Which is the user running PHP inside my_webapp? Where are modifications to make, the PHP-Srcrpts are allowed creating subdirs and so on?

[tituspijean]

Which is the user running PHP inside my_webapp?

The user would be my_webapp if you have only one instance of the app. Otherwise, check its ID from the webadin.

[mave-git]

Thanks. Never mind. I've installations of the CMS in my_webapp, my_webapp__2, my_webapp__3. In everyone of these it doesn't work. Should be the user not be "my_webapp___x" based on the app installation?

Add: "check its ID from the webadin." ???

[tituspijean]

That's what I was implying. The user should be my_webapp__2 for the second instance, and so on. The PHP config is correct for that, cf. the conf directory of this repo.

The user does have write access to its www directory.

I have just tried running a simple php script from the command line, that writes a new file, and it works. :/

[mave-git]

... a miracle ;-)
I'm not a php programmer. Could you give me this simple script for testing on my system?

[tituspijean]

Shameless copy-paste from: https://linuxhint.com/write-file-php/

Create a new php file test.php with the following contents, in /var/www/my_webapp/www/:

<?php

//Define the filename
$filename = "newfile1.txt";
//Print the file content
echo "<h3>The content of the file before update:</h3>";
echo [file_get_contents](http://www.php.net/file_get_contents)($filename);
//Open the file for reading
$file_handler = [fopen](http://www.php.net/fopen)($filename, 'a+');
//Check the file handler is created or not
if(!$file_handler)
    //Print the error message
    [die](http://www.php.net/die)("The file can't be open for writing<br />");
else
{
    //Write the particular content in the file
    $data = "This is the second line of the file.<br />";
    [fwrite](http://www.php.net/fwrite)($file_handler, $data);
    //Close the file
    [fclose](http://www.php.net/fclose)($file_handler);
    //Print the success message
    echo "<p style='font-size:20px;color:blue'>The file is updated with the content.</p>";
}
//Print the file content
echo "<h3>The content of the file after update:</h3>";
echo [file_get_contents](http://www.php.net/file_get_contents)($filename);
?>

Run it either by opening it in the browser or by running the command line: sudo -u my_webapp php8.0 -f /var/www/my_webapp/www/test.php.

Test both ways and delete newfile1.txt between attempts, as the CLI might have different rights than FPM (via the browser).

[mave-git]

Will do it (later). Thanks!

[mave-git]

Uuups ... ;-)

root@freiesachen:/var/www/my_webapp__3/www# sudo -u my_webapp__3 php8.0 -f /var/www/my_webapp__3/www/test.php
PHP Parse error:  syntax error, unexpected token "if" in /var/www/my_webapp__3/www/test.php on line 11

root@freiesachen:/var/www/my_webapp__3/www# sudo -u my_webapp__3 php7.4 -f /var/www/my_webapp__3/www/test.php
PHP Parse error:  syntax error, unexpected ':', expecting ')' in /var/www/my_webapp__3/www/test.php on line 7
root@freiesachen:/var/www/my_webapp__3/www#

Seems to be another trouble. Tried php 8.0 and 7.4, pasted the code exactly.
Additionally sorry: I forgot to mentioned: the problem caused for a modul that writes in a hidden subdir:

drwxr-xr-x  3 my_webapp__3 my_webapp__3 4096 Feb  7 21:36 .
drwxr-xr-x 14 my_webapp__3 www-data     4096 Feb  7 21:55 ..
-rw-r--r--  1 my_webapp__3 my_webapp__3    0 Feb  7 21:35 .empty
drwxr-xr-x  3 my_webapp__3 my_webapp__3 4096 Feb  7 21:36 **.news_img**

inside ==>

drwxr-xr-x 3 my_webapp__3 my_webapp__3 4096 Feb  7 21:36 .
drwxr-xr-x 3 my_webapp__3 my_webapp__3 4096 Feb  7 21:36 ..
-rw-r--r-- 1 my_webapp__3 my_webapp__3  425 Feb  7 21:36 index.php
drwxr-xr-x 2 my_webapp__3 my_webapp__3 4096 Feb  7 21:36 thumb

A member of the WBCE CMS forum asked me, if there is a problem with hidden directories (?)

[mave-git]

So, I created based on above/linuxhint.com/write-file-php this one:

<?php

//Define the directory
$subdir = "media/.news_img/99";

$dir_handler = file_exists($subdir);
if(!$dir_handler)
	mkdir($subdir);

//Define the filename
$filename = "$subdir/newfile1.txt";

//Open the file for reading
$file_handler = fopen($filename, 'w');
//Check the file handler is created or not
if(!$file_handler)
    //Print the error message
    die("The file can't be open for writing<br />");
else
{
    //Write the particular content in the file
    $data = "This is the first line of the file.<br />";
    fwrite($file_handler, $data);
    //Close the file
    fclose($file_handler);
    //Print the success message
    echo "<p style='font-size:20px;color:blue'>The file is created with the content.</p>";

    //Print the file content
    echo "<h3>The content of the file after creation:</h3>";
    echo file_get_contents($filename);
}
?>

Worked on the hidden directory. Seems to be a problem on CMS-side. ;-) Thanks for your support until now!

[mave-git]

So, the origin problem changed ;-), look:

In communication with the WBCE developer I tried debugging the code on this behaviour. Nothing to see, but. I created two exactly same installations: Yunohost: oejv-bayern.freiesachen.de and on Hetzner Webspace: nwi.mvtool.de (Apache!)
On Test-Site on Yunohost-Server and my_webapp__3 all pictures are placed at correct location but if calling them, it runs in 403 forbidden. Example: https://oejv-bayern.freiesachen.de/media/.news_img/test02.jpg.

The same file on nwi.mvtool.de: https://nwi.mvtool.de/media/.news_img/test02.jpg

Conclusion: Thoughts about wrong file writing seems to be not correct. Could be a nginx-thing: files written by scripts maybe run in this error. Files written via SFTP in may_webapp__x are okay. So, is it a nginx-configuration of Yunohost or the sub-parts in my_webapp ???

[mave-git]

News: The problem seems to be narrowed down: within my_webapp access to a hidden directory generates a 403 error. That's a configuration thing inside nginx. Where: Yunohost global or my_webapp additions?

[mave-git]

Found the "issue" in case of my system WBCE: my_webapp blocks hidden fiels and folders. I found this in the app-nginx config (/etc/conf.d/domain.tld.d/my_webapp[__x].conf)

# Deny access to hidden files and directories
    location ~ ^__PATH__/(.+/|)\.(?!well-known\/) {
        deny all;
    }

What's the reason for this decision?

[tituspijean]

Great investigation! :) Pinging @YunoHost-Apps/apps-group for more insights, but I guess it's because hidden files are meant to be... hidden. 😛

You want to circumvent that, either configure the CMS to rely on a non-dotted directory, or change the block you quoted with:

# Deny access to hidden files and directories
    location ~ ^__PATH__/(.+/|)\.(?!well-known\/|news_img\/) {
        deny all;
    }

[alexAubin]

The original commit doesn't say much about this: 1e98b92

But I could see one motivation, which is that people could be tempted to git clone some repo, and sometimes the remote may contain a token (for example to be able to git pull which more and more requires authentication) - or the git history could contain secrets etc. More generally, any hidden folder may be thought as a safe way to store secret etc...

Dunno if that's a good enough motivation but that's my 2 cents ;P

[mave-git]

Thanks for your comments! I talked to the developer of the CMS WBCE and the specific module has its reason using a hidden folder. And Yunohost/my_webapps has its own reasons. Crashing motivations ;-).
The code above is known, but will renewed when my_webapp is updating - or?
I saw the automatic including *.conf-files from /etc/nginx/conf.d/DOMAIN.LTD.d/ and tried a nginx command inside an additionally file to overwrite the standard blocking of hidden files/folders. But this does not work yet.
So, maybe creating an new ynh-package for this CMS, using its own nginx-controlling ... ;-)

[tituspijean]

Check out the hooks system from our documentation. A hook script can be triggered whenever your webapp is upgraded so that its nginx conf file is always set to your liking.