Write access to config directory by web server should not be required, should it?

[phep]

Code of Conduct

• I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• I have searched the existing issues

Version

9.5.12

Bug description

Hi,

Since we upgraded to 9.5 we have a problem due to the fact that our 'config'
directory is not writable by the HTTP server process (www-data user on our
Debian server).

So far, putting aside the warning on the system configuration page, this only
impacts us when we update the user list from our LDAP directory using the
ldap:sync command. This command used to be run from a cron job as su -s /bin/sh -c "/usr/bin/php /usr/local/share/glpi/bin/console ldap:sync ..." www-data but now this fails with the stack trace in the next section.

Of course running this CLI command as root does the trick but this is
unfortunate since it changes ownership of some sessions file to root and
requires an additional chmod on the files directory.

I know this is a 9.5 issue but I had an (admittedly quick) glance at the 10.0
code and it looks as if this behaviour is still present.

Would it be possible to lower this requirement down so that it only emits a
notice and does not block execution of commands immune to this restriction, at
least.

If this is not possible I think that this requirement should be prominently
advertised and its motivations clearly exposed since it looks as if it goes
against all best practices.

By the way, if I recall correctly, it once used to be a recommendation of GLPI
install doc to restrict write access to the config directory.

Relevant log output

[2023-02-08 08:59:20] glpiphplog.WARNING:   *** PHP Warning (2): mkdir(): Permission denied in /usr/local/share/glpi/inc/toolbox.class.php at line 1520
  Backtrace :
  inc/toolbox.class.php:1520                         mkdir()
  .../requirement/directorywriteaccess.class.php:110 Toolbox::testWriteAccessToDirectory()
  ...m/requirement/abstractrequirement.class.php:103 Glpi\System\Requirement\DirectoryWriteAccess->check()
  ...m/requirement/abstractrequirement.class.php:133 Glpi\System\Requirement\AbstractRequirement->doCheck()
  inc/system/requirementslist.class.php:71           Glpi\System\Requirement\AbstractRequirement->isOutOfContext()
  inc/console/application.class.php:469              Glpi\System\RequirementsList->hasMissingMandatoryRequirements()
  inc/console/application.class.php:245              Glpi\Console\Application->checkCoreMandatoryRequirements()
  vendor/symfony/console/Application.php:271         Glpi\Console\Application->doRunCommand()
  vendor/symfony/console/Application.php:147         Symfony\Component\Console\Application->doRun()
  bin/console:102

Page URL

No response

Steps To reproduce

What to do:

• run the ldap:sync command as the web server user (www-data) as explained above

What is expected:

• the command succeeds (provided everything else is OK)

What happens:

• the above stack trace is displayed

Your GLPI setup information

No response

Anything else?

No response

[cedric-anne]

Hi,

This is indeed a check that should not be done unless for some commands that may requires to update DB configuration.

As a workaround, you can comment this line:

glpi/inc/system/variables.class.php

Line 52 in 7a19ca0

GLPI_CONFIG_DIR,

I already encountered this behaviour but forgot to handle it. Removing write right to web server on this directory once GLPI is installed/updated is a good idea to enforce GLPI security, so this case is legitimate and should be handled correctly.

[phep]

OK, I just fixed and tested it on our instance.
Thanks for your prompt reply.

[Loiseau2nuit]

Hi there ! For all we know, this was still not fixed in GLPI 10.0.9 (see #15424 submitted by my colleague last month)
Where are we on this one ?
Thanks in advance for any feedback

[cedric-anne]

Fixed by #15772