Var lib php session permission

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

puphpet / puphpet Public archive

(CentOS) PHP session.save_path is set but permissions not adjusted #274

(CentOS) PHP session.save_path is set but permissions not adjusted #274

Comments

In the ini section of the common.yaml , the session.save_path is set to /var/lib/php/session but Apache doesn’t have write permissions for that folder.

The text was updated successfully, but these errors were encountered:

This might not be a proper security fix but it was quick and worked: In common.yaml, set user and group to ‘apache’ in the apache section.

Would it be better if in shell/initial-setup.sh, below the condition if CentOS there would be a line like this?

chown -R root:www-data /var/lib/php/session

I have the same error.
but it’s strange, because the following configuration should do the job:

if $php_values['ini']['session.save_path'] != undef < exec ": onlyif => "test ! -d $", > file < $php_values['ini']['session.save_path']: ensure =>directory, group => 'www-data', mode => 0775, require => Exec["mkdir -p $"] > > 

The config shows the group as www-data and permissions as 0775 , but this is what I actually ended up with:

02:16 PM]-[vagrant@localhost]-[/var/lib/php] $ ll total 4 drwxrwx--- 2 root apache 4096 Jan 9 06:37 session/ 

root is owner, apache is the group, permissions aren’t set to 0775 .

I’m completely new at this, so not sure why this config isn’t being used, but an alternative could be to set your sessions folder to /tmp . I think that is writable to all?

I generated a puphpet config last week and new devs have reported that setting up their box for the first time the session directory is not writable resulting in a fatal error.

Hi, I’m facing this issue using a fresh generated puphpet. The php.save_path config setting is set to /var/lib/php/session , but when the initial vagrant up finishes, I see that the php.save_path directory has root:apache ownership rather than the expected www-data:www-data ownership.

[03:01 PM]-[vagrant@localhost]-[/var/lib/php] $ ls -l total 4 drwxrwx--- 2 root apache 4096 Feb 18 15:49 session/ 

I found the following section of code in ./puphpet/puppet/nodes/Php.pp that seems to be getting ignored:

if hash_key_true($php_values['ini'], 'session.save_path')< $php_sess_save_path = $php_values['ini']['session.save_path'] # Handles URLs like tcp://127.0.0.1:6379 # absolute file paths won't have ":" if ! (':' in $php_sess_save_path) < exec ": creates => $php_sess_save_path, before => Class['php'] > -> file < $php_sess_save_path: ensure =>directory, group => 'www-data', owner => 'www-data', mode => '0775', > > > 

The full config.yaml file is:

--- vagrantfile-local: vm: box: puphpet/centos65-x64 box_url: puphpet/centos65-x64 hostname: '' memory: '4096' cpus: '4' chosen_provider: virtualbox network: private_network: 192.168.56.101 forwarded_port: zZPYhZiJsZrm: host: '5077' guest: '22' post_up_message: '' provider: virtualbox: modifyvm: natdnshostresolver1: on vmware: numvcpus: 1 parallels: cpus: 1 provision: puppet: manifests_path: puphpet/puppet manifest_file: site.pp module_path: puphpet/puppet/modules options: - '--verbose' - '--hiera_config /vagrant/puphpet/puppet/hiera.yaml' - '--parser future' synced_folder: < >usable_port_range: start: 10200 stop: 10500 ssh: host: null port: null private_key_path: null username: vagrant guest_port: null keep_alive: true forward_agent: false forward_x11: false shell: 'bash -l' vagrant: host: detect server: install: '1' packages: - vim-common - mercurial - htop - mc - php-xml users_groups: install: '1' groups: < >users: < >cron: install: '1' jobs: < >firewall: install: '1' rules: < >apache: install: '1' settings: user: www-data group: www-data default_vhost: true manage_user: false manage_group: false sendfile: 0 modules: - rewrite vhosts: < >mod_pagespeed: 0 nginx: install: '0' settings: default_vhost: 1 proxy_buffer_size: 128k proxy_buffers: '4 256k' upstreams: < >vhosts: r2zlxmr1qjpy: proxy: '' server_name: awesome.dev server_aliases: - www.awesome.dev www_root: /var/www/awesome listen_port: '80' location: \.php$ index_files: - index.html - index.htm - index.php envvars: - 'APP_ENV dev' engine: php client_max_body_size: 1m ssl_cert: '' ssl_key: '' php: install: '1' version: '54' composer: '1' composer_home: '' modules: php: - cli - intl - mbstring - mcrypt pear: < >pecl: - memcached - pecl_http - xmlReader - xmlwriter ini: display_errors: On error_reporting: '-1' session.save_path: /var/lib/php/session html_errors: On short_open_tag: On max_execution_time: '360' post_max_size: 100M upload_max_filesize: 100M max_input_vars: '10000' memory_limit: 2048M sendmail_path: /usr/bin/catchmail suhosin.post.max_value_length: '67108864' suhosin.post.max_vars: '10000' suhosin.request.max_vars: '10000' timezone: Europe/London mod_php: '1' hhvm: install: '0' nightly: 0 composer: '1' composer_home: '' settings: host: 127.0.0.1 port: '9000' ini: display_errors: On error_reporting: '-1' timezone: null xdebug: install: '1' settings: xdebug.default_enable: '1' xdebug.remote_autostart: '0' xdebug.remote_connect_back: '1' xdebug.remote_enable: '1' xdebug.remote_handler: dbgp xdebug.remote_port: '9000' xhprof: install: '0' wpcli: install: '0' version: v0.17.1 drush: install: '0' version: 6.3.0 ruby: install: '1' versions: < >nodejs: install: '1' npm_packages: - gulp python: install: '1' packages: < >versions: < >mysql: install: '1' override_options: < >root_password: '123' adminer: '1' databases: < >postgresql: install: '0' settings: root_password: '123' user_group: postgres encoding: UTF8 version: '9.3' databases: < >adminer: 0 mariadb: install: '0' override_options: < >root_password: '123' adminer: 0 databases: < >version: '10.0' sqlite: install: '1' adminer: 0 databases: < >mongodb: install: '0' settings: auth: 1 port: '27017' databases: < >redis: install: '0' settings: conf_port: '6379' mailcatcher: install: '1' settings: smtp_ip: 0.0.0.0 smtp_port: 1025 http_ip: 0.0.0.0 http_port: '1080' mailcatcher_path: /usr/local/rvm/wrappers/default from_email_method: headers beanstalkd: install: '1' settings: listenaddress: 0.0.0.0 listenport: '13000' maxjobsize: '65535' maxconnections: '1024' binlogdir: /var/lib/beanstalkd/binlog binlogfsync: null binlogsize: '10485760' beanstalk_console: '1' binlogdir: /var/lib/beanstalkd/binlog rabbitmq: install: '0' settings: port: '5672' elastic_search: install: '0' settings: version: 1.4.1 java_install: true solr: install: '0' settings: version: 4.10.2 port: '8984' 

Let me know if you need any else from me to look into this further.

Источник

Question Default Owner of /var/lib/php

What are the defualt permission and owner for directory ‘/var/lib/php/sessions’.

Since I upgraded to Onyx and Ubuntu 16, the default dir owner of ‘var/lib/php’ was root : root. I changed to www-data : psacln but I am getting the same error.

UFHH01

Guest

The correct permissions are:

What makes you think, that these are the correct permissions?

Pls. post the output of the following commands from your command line:

stat /var/lib/php/sessions find /etc/php -type f -name "php.ini" -exec grep --color -Hni "session.save_path" <> \; | grep --color -Hni /var/lib/php find /etc/php5 -type f -name "php.ini" -exec grep --color -Hni "session.save_path" <> \; | grep --color -Hni /var/lib/php find /opt/plesk -type f -name "php.ini" -exec grep --color -Hni "session.save_path" <> \; | grep --color -Hni /var/lib/php

Izaim

Basic Pleskian

The correct permissions are:

What makes you think, that these are the correct permissions?

Pls. post the output of the following commands from your command line:

stat /var/lib/php/sessions find /etc/php -type f -name "php.ini" -exec grep --color -Hni "session.save_path" <> \; | grep --color -Hni /var/lib/php find /etc/php5 -type f -name "php.ini" -exec grep --color -Hni "session.save_path" <> \; | grep --color -Hni /var/lib/php find /opt/plesk -type f -name "php.ini" -exec grep --color -Hni "session.save_path" <> \; | grep --color -Hni /var/lib/php

stat /var/lib/php/sessions
File: ‘/var/lib/php/sessions’
Size: 1921024 Blocks: 3760 IO Block: 4096 directory
Device: 902h/2306d Inode: 63442989 Links: 2
Access: (7733/drws-ws-wt) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2016-12-08 01:14:00.976597900 +0100
Modify: 2016-12-08 01:14:14.000642343 +0100
Change: 2016-12-08 01:14:14.000642343 +0100
Birth: —

find /etc/php -type f -name «php.ini» -exec grep —color -Hni «session.save_path» <> \; | grep —color -Hni /var/lib/php
(standard input):3:/etc/php/7.0/cgi/php.ini:1306:;session.save_path = «/var/lib/php/sessions»
(standard input):7:/etc/php/7.0/fpm/php.ini:1306:;session.save_path = «/var/lib/php/sessions»
(standard input):11:/etc/php/7.0/cli/php.ini:1306:;session.save_path = «/var/lib/php/sessions»
(standard input):15:/etc/php/7.0/apache2/php.ini:1306:;session.save_path = «/var/lib/php/sessions»

NO PHP5 DIR, I DONT USE PHP5.

find /opt/plesk -type f -name «php.ini» -exec grep —color -Hni «session.save_path» <> \; | grep —color -Hni /var/lib/php
(standard input):3:/opt/plesk/php/7.0/etc/php.ini:1318:session.save_path = «/var/lib/php/sessions»

Источник

Question Incorrect permissions on /var/lib/php/session

We are running Plesk Onyx (Version 17.5.3 Update #33) on CentOS, a colleague of mine was trying to us Larvel and to use one of the tools he had to upgrade the built in version of PHP from 5 to 7.1 so used yum to do the update. This then broke Plesk (probably because between PHP 5 and 7 some file paths have changed), and as such he then had to reverse the upgrade and downgrade back to PHP 5.

As a result of this permissions on /var/lib/php/session must have been changed because we were getting permission errors when PHP tried to store session data.

I was able to fix this but wanted to know if this was a known issue, as any documentation I found on Plesk’s site said that this issue of permissions being set incorrectly had been fixed.

Additionally I’d like to know if there are any plans to update Plesk so it doesn’t require PHP 5 to be installed because in an ideal world we shouldn’t need to even have PHP 5 installed anymore.

virtubox

Regular Pleskian

We are running Plesk Onyx (Version 17.5.3 Update #33) on CentOS, a colleague of mine was trying to us Larvel and to use one of the tools he had to upgrade the built in version of PHP from 5 to 7.1 so used yum to do the update. This then broke Plesk (probably because between PHP 5 and 7 some file paths have changed), and as such he then had to reverse the upgrade and downgrade back to PHP 5.

As a result of this permissions on /var/lib/php/session must have been changed because we were getting permission errors when PHP tried to store session data.

I was able to fix this but wanted to know if this was a known issue, as any documentation I found on Plesk’s site said that this issue of permissions being set incorrectly had been fixed.

Additionally I’d like to know if there are any plans to update Plesk so it doesn’t require PHP 5 to be installed because in an ideal world we shouldn’t need to even have PHP 5 installed anymore.

Plesk use specific php-packages. If your colleague used yum install to add a php version, it’s not correct.
You can add or remove php packages from the Plesk installer with the web interface or with the CLI.

Normal permissions for /var/lib/php/sessions are 1777.
So you can use

chmod 1777 /var/lib/php/sessions

Источник