Adjusting the permissions of directories and files.

[Lu-Wi]

Hi,

I get the following error message trying to install part-db.

The thing is, I have made sure that the permissions are set as mentioned in the installation guide:

cd /var/wwww
sudo chown -R www-data: www-data part-db
find part-db -type d -print0 | sudo xargs -0 chmod 555
find part-db -type f -print0 | sudo xargs -0 chmod 444
find part-db/data -type d -print0 | sudo xargs -0 chmod 755
find part-db/data -type f -print0 | sudo xargs -0 chmod 644"

(By the way ther is a typo in the guide it says "wwww")

Nevertheless the issue occures. The installed files are located in "/var/www/html" and the user who is runnig apache is "www" instead of "www-data" which is configured in the apache config. The files are located in /etc/httpd/conf/httpd.conf (Centos) in my case. I also enabled the .httpaccess files by allowing the overwrite for "/var/www/html" and its subdirectories.

So I am actually not sure what else I can change. I have been trying to fix it the last hour but it does not seem to work. I cloned the git repository and did not copy the master.zip for the installation. Could it be the current verison or what else could I try?

I am looking forward the hear from someone. :)

Best regards,

LuWi

[jbtronics]

Have you opened Part-DB in your browser before you applied these permissions? It seems that PHP caches the stats about files (and their permissions), so it does not get it when you change the file permissions…

I would guess, that when you restart PHP and/or your webserver, the problem will be gone.

When this does not work you can try to create a file like "test.php" in the Part-DB folder with the content <?php clearstatcache() and open the file in browser.

If that does work for you, I will try to implement that Part-DB clears the cache automatically...

[Lu-Wi]

Unfortunatelly this did not work. I wrote a little php script:

<?php

clearstatcache();

$file = './part-db/data';
$stat = stat($file);

function get_owner($file, $stat)
{
    $user = posix_getpwuid($stat['uid']);
    return $user['name'];
}

function get_group($file, $stat)
{
    $group = posix_getgrgid($stat['gid']);
    return $group['name'];
}

printf($file . "%s", " ");
printf(substr(sprintf('%o', fileperms($file)), -4) . "%s", " - ");
printf("%s" . "%s", get_owner($file, $stat), ":");
printf("%s", get_group($file, $stat));

?>

and called it from the browser and the console:

sudo -u www -H php clear.php
./part-db/data 0755 - www:www

So the permissions seems totally fine but it still results in the upper failure message if I try to open the address:

http://xxx.x.xx.xxx/part-db

[Lu-Wi]

Additionally, here the output of checking the apache operator which is also the user www:

ps aux | egrep '(apache|httpd)'
root      3647  0.0  0.8 381392 15440 ?        Ss   18:49   0:00 /usr/sbin/httpd -DFOREGROUND
www       3648  0.0  0.5 381656 10716 ?        S    18:49   0:00 /usr/sbin/httpd -DFOREGROUND
www       3649  0.0  0.5 485328 10964 ?        S    18:49   0:00 /usr/sbin/httpd -DFOREGROUND
www       3650  0.0  0.4 381524  9344 ?        S    18:49   0:00 /usr/sbin/httpd -DFOREGROUND
www       3651  0.0  0.5 381656 10668 ?        S    18:49   0:00 /usr/sbin/httpd -DFOREGROUND
www       3652  0.0  0.5 381524 10164 ?        S    18:49   0:00 /usr/sbin/httpd -DFOREGROUND
www       3653  0.0  0.5 485328 10964 ?        S    18:49   0:00 /usr/sbin/httpd -DFOREGROUND
www       3855  0.0  0.4 381392  8596 ?        S    19:27   0:00 /usr/sbin/httpd -DFOREGROUND

[jbtronics]

That's really strange... I will investigate this problems in the next days a bit more...

But for now as a workaround you can do this: In the file start_session.php replace the line $messages = checkFilePermissions() with $messages = array() this should override the Permissions check and you should be able to use Part-DB...

[Lu-Wi]

I tweaked the inc/lib.start_session.php by adding the three functions:

function get_owner($file)
{
    $stat = stat($file);
    $user = posix_getpwuid($stat['uid']);
    return $user['name'];
}

function get_group($file)
{
    $stat = stat($file);
    $group = posix_getgrgid($stat['gid']);
    return $group['name'];
}

function get_permission($file)
{
    $permission = substr(sprintf('%o', fileperms($file)), -4);
    return $permission;
}

and by modified the checkFilePermissions() as following:

function checkFilePermissions()
{
[...]
    foreach ($permissions as $filename => $needed_perms) {
        $whole_filename = BASE.$filename;

        echo "<br/>";
        echo $whole_filename;

        if (! file_exists($whole_filename)) {
[...]
        $is_executable = (is_executable($whole_filename) || @file_exists($whole_filename.'.'));

        echo " ";
        echo get_owner($whole_filename), ":";
        echo get_group($whole_filename), " ";
        echo get_permission($whole_filename), " ";
        echo "curr_user: ", `whoami`;

        if (((strpos($needed_perms, 'r') !== false) && (! is_readable($whole_filename)))
            || ((strpos($needed_perms, 'w') !== false) && (! is_writable($whole_filename)))
            || ((strpos($needed_perms, 'x') !== false) && (DIRECTORY_SEPARATOR == '/') && (! $is_executable))) { // check for execution bit only for UNIX/Linux
            $messages[] =   sprintf(_('Das Verzeichnis bzw. die Datei "%s" hat nicht die richtigen Dateirechte! '), $filename).
                sprintf(_('Benötigt werden "%s". Bitte manuell korrigieren.'), str_replace('e', '', $needed_perms));
        }
[...]

which resulst in: (FYI during testing I changed the user who is runnig the apache back to the original user apache. Therfore, I also changed the ownership of part-db to the user and group apache)

However trying to do you temporary fix from the post above:

/***************************************
 * Temp fix                            *
 ***************************************
 * $messages = checkFilePermissions(); *
 ***************************************/
 $message = Array();

is resulting in:

[Lu-Wi]

FYI:

php --version
PHP 7.2.11 (cli) (built: Oct 16 2018 14:30:41) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.11, Copyright (c) 1999-2018, by Zend Technologies

And I also tried the version 7.0.23

[jbtronics]

Does the user of the webserver have permissions to create folders/write into the Part-DB main folder? It needs to create a folder named templates_c for caching. The second message seems like the webserver does not have the right permission to do that..

I'm not sure if that is related to the problem that the permissions of the data folder are not detected properly, but I would be interested what happens if you give part-db write access to main folder.

[Lu-Wi]

I am not sure what else I could try. I did the following in the part-db folder:

sudo -u apache -H touch test.txt
sudo -u apache -H mkdir -p test

Both commands worked without an error.

[jlegen]

sudo -u apache -H touch test.txt sudo -u apache -H mkdir -p test

shouldn't this be 'sudo -u www -H mkdir -p test' for you?

if the partdb-error happens, do you have anything in the apache error log? perhaps something like "LogLevel debug" could enhance its verbosity. i once had a similar problem which at the end was related to the apache config... another try would be to enable (if not yet active) the PHP error log, also with some verbose log level...

[jbtronics]

You could try to set the key "$config['debug']['enable']" in data/config.php (or if you dont have it the one in inc/config_defaults.php, so some additional PHP error messages are shown.

The serverlog of the apache or PHP, could be intersting too...

Furthermore you could try to create the folder "templates_c/" by yourself, and try it with my temporary fix again.

[jbtronics]

You could also try to apply the permissions 777 to all Part-DB files, this is very unsafe (so you must change it afterwards), but so we can maybe determine if the problem is caused by a strange permission related thing or something else...

Something other: Do you have SELinux installed? Then maybe this helps for you: https://stackoverflow.com/questions/13908722/php-unable-to-create-a-directory-with-mkdir

[Lu-Wi]

Yes SELinux was the issue:

sestatus
SELinux status:                 enabled

a simple:

chcon -R -t httpd_sys_content_rw_t /var/www/part-db

solved the issue.

[jbtronics]

Very good :)

Ive added a hint about the SELinux thing to the Installation guide on the wiki (https://github.com/Part-DB/Part-DB/wiki/EN:-Installation#set-selinux-permission)