Bug 1227215

What is wrong with it? Is it a wrong default? Or some setups need a different permission or ownership?

On the rpm level, there are two possible solutions:

%verify(not mode) %attr(0755, %{apache_user}, root) %dir %{_localstatedir}/lib/%{php_name}


or mark these directories as %ghost, and in %pre:

mkdir -p -m 755 %{_localstatedir}/lib/%{php_name}

This will return no error, if it exists. And will not change the mode.

If it affects the owner:

%pre
if ! test -d "%{_localstatedir}/lib/%{php_name}" ; then
 mkdir -m 755 %{_localstatedir}/lib/%{php_name}
 chown %{apache_user}:root %{_localstatedir}/lib/%{php_name}
fi

%ghost %dir %{_localstatedir}/lib/%{php_name}

If the mode or owner needs to be changed for a particular module or package, then that package could contain scriptlets:

%post
chmod something %{_localstatedir}/lib/%{php_name}

%postun
if [ $1 -eq 0 ]; then
 chmod 755 %{_localstatedir}/lib/%{php_name}
fi

%triggerpost apache -- chmod something %{_localstatedir}/lib/%{php_name}

And apache package would just contain:
%verify(not mode) %attr(0755, %{apache_user}, root) %dir %{_localstatedir}/lib/%{php_name}

(In reply to Stanislav Brabec from comment #1)
> What is wrong with it? Is it a wrong default? Or some setups need a
> different permission or ownership?
> 

Nginx has its own user and group, updating php rewrites the rights for the apache user to this directory, for nginx users everything that uses php simply breaks

Adding some maintainers, which could be interested.

> >>>Requires:       group(www)
> >>>Requires:       user(wwwrun)
> >>>%attr(0755, %{apache_user}, root) %dir %{_localstatedir}/lib/%{php_name}
> >>>%attr(0755, %{apache_user}, root) %dir %{_localstatedir}/lib/%{php_name}

Feel free to correct me, this alone does not imply overwrite of permissions after upgrade, it just ensures it is in certain form. In simple case -- when certain hack Stanislav (thank you) hinted is not used -- then it will be jusst overwritten during php8 upgrade anyway.

This is perhaps a bit Apache-centric, yes, even %{apache_user} could be replaced by wwwrun string in the spec instead; nevertheless wwwrun and www sound neutral. We seem to not be alone:
https://stackoverflow.com/questions/9203320/php-fpm-and-nginx-session-problems

Ideas welcome.

Note I'll probably not be able to touch this bug next few weeks.

(In reply to Petr Gajdos from comment #4)
> Adding some maintainers, which could be interested.
> 
> > >>>Requires:       group(www)
> > >>>Requires:       user(wwwrun)
> > >>>%attr(0755, %{apache_user}, root) %dir %{_localstatedir}/lib/%{php_name}
> > >>>%attr(0755, %{apache_user}, root) %dir %{_localstatedir}/lib/%{php_name}
> 
> Feel free to correct me, this alone does not imply overwrite of permissions
> after upgrade, it just ensures it is in certain form. In simple case -- when
> certain hack Stanislav (thank you) hinted is not used -- then it will be
> jusst overwritten during php8 upgrade anyway.
> 
> This is perhaps a bit Apache-centric, yes, even %{apache_user} could be
> replaced by wwwrun string in the spec instead; nevertheless wwwrun and www
> sound neutral. We seem to not be alone:
> https://stackoverflow.com/questions/9203320/php-fpm-and-nginx-session-
> problems
> 
> Ideas welcome.
> 
> Note I'll probably not be able to touch this bug next few weeks.

It might be worth trying using conditional builds
>>>%bcond_with and %bcond_without
https://rpm-software-management.github.io/rpm/manual/conditionalbuilds.html

What is installed in /var/lib/php8? It seems wrong that either apache or nginx have any business there, unless the former is run in prefork mode (which is not a good idea).

The name suggests it is something php8 uses and the permissions should be whatever php8 is running as. This definitely does not mean it is running as the same user the webserver is, so I don't understand why it matters what nice is using internally.

In any case, bcond is not going to help here, as we only ship one version of php8, so whatever permissions are set need to be used by all.

unless you use suexec the mpm used by apache doesnt really matter it will run under wwwrun:www no matter which mpm. and i am not sure we will be able to kill mod_php any time soon. one could argue we should migrate everything to use php-fpm but I am not sure everyone will be happy about it.

in my personal setup i have php-fpm + nginx. each php app has its own user/group, apparmor scope and strict permissions for its diretories. oh and every app has its own session directory. see home:darix:apps/nextcloud or tt-rss or roundcubemail for examples.

just as an idea what we could do ... though the way how to migrate users into that is tricky:


/var/lib/php8/apache/{,sessions/} wwwrun:www u=rwX,go=

/var/lib/php8/fpm/{,session/} php:php u=rwX,go=

(In reply to Marcus Rückert from comment #8)

> /var/lib/php8/fpm/{,session/} php:php u=rwX,go=

Who owns the php:php user and group? Use of php8-fpm is not limited to nginx so we must make sure this user is available if we need to store session information there. In that case, php8 shouldn't create/modify these locations, but the respective php variant used (mod_php8 and php8-fpm respectively. But then it also means that we need to change the default group and user for php8-fpm and make sure they are available.

even the php8 package could own that user. or a separate system user package all together. and for nginx or similar webservers the only thing that matters is the user/group that is configured for the default pool. right now that is actually /etc/php8/fpm/www.conf ... which defaults to wwwrun:www. so in theory it shold work to mix fpm and mod_php on the same system with the default configuration.

Petr Gajdos, comment 4:
%attr(0755, %{apache_user}, root) %dir %{_localstatedir}/lib/%{php_name}
This alone causes permission update on any package install/reinstall/upgrade.