Web server root directory configuration is not safe

jhoux@zirrusone.com · 2023-12-15 00:50:05

Oh! Now I see where you explained this further up the thread:

"The point of that code was to determine if the first PHP script called is the index.php from the public folder. As long as you set the document root in the web config to the "public" folder inside GLPI, and then configure a rewrite for all requests so that they are redirected to the "public" folder, the GLPI code should work."

jhoux@zirrusone.com · 2023-12-15 00:59:53

So I changed the Apache DocumentRoot to glpi/public because I had it pointed at glpi.

Now, when I get redirected to mydomain.com/front/central.php, there's a 404.

I guess that means the public/index.php router isn't being reached.

Puzzling...

It is certainly an architectural issue that GLPI can be served successfully out of the root folder, and leave a person scratching their head about the error. And then trying to remediate it by switching to serving glpi/public leads to more head-beating. The onboarding experience is quite painful for some users who happen to make a mistep somewhere.

Last edited by jhoux@zirrusone.com (2023-12-15 01:00:29)

jhoux@zirrusone.com · 2023-12-15 01:11:04

I solved it. I was missing a simple directive in my VirtualHost.

There's nothing wrong with requiring VirtualHost configuration. I saw some other users complaining about it. But VirtualHost configuration can be quite frustrating when you've simply made a mistype or omitted something by accident. It would be nice if GLPI error would at least state some more information such as this:

A possible cause of this error is that you have configured your webserver to serve GLPI from the GLPI root folder. This is ill-advised. You should check your VirtualHost and make sure your server DocumentRoot is glpi/public.

Last edited by jhoux@zirrusone.com (2023-12-15 01:13:14)

jhoux@zirrusone.com · 2023-12-15 01:17:02

Does this have any impact on the API endpoints?

cconard96 · 2023-12-15 02:07:37

There is no impact on API endpoints, at least in the fact that they are all the same URLs as before. They DO go through the new public router, but just like the web URLs, the redirect is all done transparently.

krishnateja.ks · 2024-01-10 09:00:59

Web server root directory configuration is not safe as it permits access to non-public files. See installation documentation for more details.

soultion :

go to Xampp-> httdocs->glpi/src/system/Requirment/safedocumentroot.php

open safedocumentroot.php and go to end of the page..

on the script add a line " return; "

$initial_script = get_included_files()[0] ?? '';
if (realpath($initial_script) === realpath(sprintf('%s/public/index.php', GLPI_ROOT))) {
// Configuration is safe if install/update script is accessed through `public/index.php` router script.
$this->validated = true;
$this->validation_messages[] = __('Web server root directory configuration seems safe.');
} else {
$this->validated = false;
return; (add this line)
$this->validation_messages[] = __('Web server root directory configuration is not safe as it permits access to non-public files. See installation documentation for more details.');
}

cconard96 · 2024-01-10 18:29:40

I definitely don't recommend simply hiding the warning by modifying the GLPI code. This will be a required step in GLPI 10.1 and I recommend at least attempting the configuration now; both to ease the migration to GLPI 10.1 and so we can improve our documentation on the implementation of this configuration if there are edge-case issues.

emrd · 2024-02-04 11:12:30

Nginx config that fixed it for me, glpi version 10.0.12

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name glpi.local.glpi;
    return 301 https://$host$request_uri; # Redirect HTTP to HTTPS
}

server {
    listen 443 ssl http2 default_server;
    listen [::]:443 ssl http2 default_server;
    ssl_certificate /etc/ssl/certs/local.glpi.crt;
    ssl_certificate_key /etc/ssl/private/local.glpi.key;
    
    # Set the root to point to the public directory inside GLPI
    root /var/www/html/glpi/public;
    index index.php index.html index.htm;
    server_name glpi.local.glpi;

    # Correctly route requests to index.php if the requested file or directory does not exist
    location / {
        try_files $uri $uri/ /index.php$is_args$args;
    }

    # Explicitly handle requests to index.php, ensuring fastcgi parameters are correctly passed
    location ~ ^/index\.php(/|$) {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    # Deny access to .htaccess and other hidden files
    location ~ /\.ht {
        deny all;
    }

    access_log /var/log/nginx/access-glpi.log;
    error_log /var/log/nginx/error-glpi.log;
}

Last edited by emrd (2024-02-04 11:16:14)

Gestinfo · 2024-03-05 12:32:09

Hi all,

I have a communication problem with OCS Inventory after i updated GLPI to version 10.0.11.
The 2 applications are on the same server.

So after upgrading GLPI, i adapted the apache config file as below to match the public folder.

<VirtualHost _default_:443>
                ServerAdmin webmaster@localhost

                DocumentRoot /var/www/glpi/public
                
<Directory /var/www/glpi/public>
        Require all granted

        RewriteEngine On

        # Ensure authorization headers are passed to PHP.
        # Some Apache configurations may filter them and break usage of API, CalDAV, ...
        RewriteCond %{HTTP:Authorization} ^(.+)$
        RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

        # Redirect all requests to GLPI router, unless file exists.
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteRule ^(.*)$ index.php [QSA,L]
 </Directory>

 ErrorLog ${APACHE_LOG_DIR}/error.log
 CustomLog ${APACHE_LOG_DIR}/access.log combined

SSLEngine on


SSLCertificateFile      /etc/apache2/ssl/gestparc.crt
SSLCertificateKeyFile /etc/apache2/ssl/gestparc.key

<FilesMatch "\.(cgi|shtml|phtml|php)$">
                  SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
                  SSLOptions +StdEnvVars
</Directory>

</VirtualHost>

And after that, OCS Inventory didnt worked.
I had an error HTTP 403 which i guess is normal with the new secure method.

I tried the solution with Alias that @ajavor wrote below but after that i get an HTTP 400.
If i uncomment the same rewrite lines it is working but not GLPI.

I understand the thing that i have to tell apache to catch the ocsinventory folder, the problem that is it a "virtual" folder who calls some Perl script.

So i dont really know what do i have to do.

If someone have an idea ?

Thanks.

ajavor wrote:

Hi @WebGreg
I see you are also using OCS Inventory on the same server as GLPI.
I updated GLPI to version 10.0.7 according to the instructions (removed the entire glpi directory, uploaded the new version, restored the folders: config, files, marketplace and plugins from the backup and finally updated the database).
Apache2 configuration identical as above - GLPI works flawlessly, but OCS clients stopped connecting to the server.
When in the apache2 configuration I comment out the following lines:
  #RewriteEngine On

# Redirect all requests to GLPI router, unless file exists.
  #RewriteCond %{REQUEST_FILENAME} !-f
  #RewriteRule ^(.*)$ index.php [QSA,L]
then communication to clients to OCS starts working, but of course GLPI doesn't work anymore.
Any hint how to run it now so that both OCS and GLPI systems run in parallel, as before the update GLPI?
update:
This is a "Virtual" directory for handling OCS Inventory NG agents communications. In apache2 conf it looks like this:
<Location /ocsinventory>
          order deny,allow
          allow from all
          SetHandler perl-script
          PerlHandler Apache::Ocsinventory
  </Location>
update2:
OK, I'll answer myself. In apache configuration add:
  AliasMatch "/ocsinventory" "/var/www/glpi/ocsinventory"

Forum GLPI-Project

Announcement

#51 2023-12-15 00:50:05

Re: Web server root directory configuration is not safe

#52 2023-12-15 00:59:53

Re: Web server root directory configuration is not safe

#53 2023-12-15 01:11:04

Re: Web server root directory configuration is not safe

#54 2023-12-15 01:17:02

Re: Web server root directory configuration is not safe

#55 2023-12-15 02:07:37

Re: Web server root directory configuration is not safe

#56 2024-01-10 09:00:59

Re: Web server root directory configuration is not safe

#57 2024-01-10 18:29:40

Re: Web server root directory configuration is not safe

#58 2024-02-04 11:12:30

Re: Web server root directory configuration is not safe

#59 2024-03-05 12:32:09

Re: Web server root directory configuration is not safe

Board footer