PHP无法从NFS共享读取会话 [英] PHP cannot read sessions from NFS share

问题描述

我将我的PHP会话文件存储在NFS共享上.问题是，PHP总是创建一个空的会话文件，但无法从中读取/写入，因此对于每次重新加载页面都会创建一个新文件.

如果我将会话存储路径移动到本地文件夹，则将正常保存会话.另外，我正在运行具有相同配置的另一个环境，并且运行良好.

在PHP出现此问题的同一台服务器上，我能够在保存会话的同一目录中创建/写入/读取文件(使用root，非root用户，特别是www-data用户进行了测试). /p>

我在Ubuntu 12.04 LTS上使用PHP 5.5.12，Apache 2.4.9和NFS v3

我的php.ini

session.save_handler = files
session.save_path = "2;/mnt/cache/sessions"
session.use_cookies = 1
session.use_only_cookies = 0
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 2592000
session.cookie_path = /
session.cookie_domain =
session.cookie_httponly =
session.serialize_handler = php
session.gc_probability = 1
session.gc_divisor = 1000
session.gc_maxlifetime = 2592000
session.bug_compat_42 = Off
session.bug_compat_warn = Off
session.referer_check =
session.entropy_length = 0
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 0
session.hash_function = 0
session.hash_bits_per_character = 5

我的/etc/fstab

nfs-srv.local:/export/cache   /mnt/cache   nfs    rw,hard,intr  0  0

我的/etc/exports在nfs-srv.local上

/export/cache 10.1.10.0/24(rw,nohide,insecure,no_subtree_check,async,all_squash,anonuid=33,anongid=33)

会话文件

ls /mnt/cache/sessions/ -l
drwxrwxrwx 34 nobody nogroup 4096 May 16 10:33 0
drwxrwxrwx 34 nobody nogroup 4096 May 16 10:33 1
drwxrwxrwx 34 nobody nogroup 4096 May 16 10:33 2
...

ls /mnt/cache/sessions/m -l
drwxrwxrwx 2 nobody nogroup 4096 May 16 10:33 0
drwxrwxrwx 2 nobody nogroup 4096 May 16 12:18 1
drwxrwxrwx 2 nobody nogroup 4096 May 16 10:33 2
drwxrwxrwx 2 nobody nogroup 4096 May 16 10:33 3
drwxrwxrwx 2 nobody nogroup 4096 May 16 12:16 4
drwxrwxrwx 2 nobody nogroup 4096 May 16 12:14 5
...

ls /mnt/cache/sessions/m/5 -l
-rw------- 1 nobody nogroup 0 May 16 12:14 sess_m5ifehvhkjdisp7dgtiuu601e2

解决方案

我认为我已经找到了此问题的根本原因，从PHP 5.5.10升级到5.6.5时也遇到了该问题.

PHP 5.5.12更改日志列出了以下错误修正:

当session.save_path是每个人都可以写入的目录时 (例如在Debian上)，即使无法找到的ID 现有会话，本地攻击者只能创建一个新的会话文件 带有恶意会话数据，请将其更改为666并访问任何webapp 使用他选择的会话ID托管在系统上.然后，Webapp 打开会话文件，并将其视为已创建.我的解决方法: 在fstat()会话中，检查创建文件的uid.如果它是 getuid()和uid 0的结果都不要忽略现有文件.

简而言之，如果发现新创建的会话文件不属于运行Apache或root的用户帐户所有，他们将停止写入会话数据.这很荒谬，因为NFS在不同级别上实现其安全性，但是通常使用 remote UID/GID映射进行部署，并且经常被压缩.因此，Apache用户在创建文件的那一微秒内就不再拥有该文件.这意味着，从PHP 5.5.12开始(或5.4.28包含相同的修复程序")，将会话数据存储在大多数现有NFS服务器上变得不可能.

I'm storing my PHP session files on a NFS share. The issue is, that PHP always creates an empty session file, but cannot read/write from it, so for each page reload a new file is created.

If I move the session store path to a local folder, sessions are saved normally. Also I'm running an another environment with the same configuration and it is working fine.

On the same server where PHP is having this issue I'm able to create/write/read files in the same directories where the sessions are saved (tested with root, non-root and specifically www-data user).

I'm using PHP 5.5.12, Apache 2.4.9 and NFS v3 on Ubuntu 12.04 LTS

My php.ini

session.save_handler = files
session.save_path = "2;/mnt/cache/sessions"
session.use_cookies = 1
session.use_only_cookies = 0
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 2592000
session.cookie_path = /
session.cookie_domain =
session.cookie_httponly =
session.serialize_handler = php
session.gc_probability = 1
session.gc_divisor = 1000
session.gc_maxlifetime = 2592000
session.bug_compat_42 = Off
session.bug_compat_warn = Off
session.referer_check =
session.entropy_length = 0
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 0
session.hash_function = 0
session.hash_bits_per_character = 5

My /etc/fstab

nfs-srv.local:/export/cache   /mnt/cache   nfs    rw,hard,intr  0  0

My /etc/exports on nfs-srv.local

/export/cache 10.1.10.0/24(rw,nohide,insecure,no_subtree_check,async,all_squash,anonuid=33,anongid=33)

Session files

ls /mnt/cache/sessions/ -l
drwxrwxrwx 34 nobody nogroup 4096 May 16 10:33 0
drwxrwxrwx 34 nobody nogroup 4096 May 16 10:33 1
drwxrwxrwx 34 nobody nogroup 4096 May 16 10:33 2
...

ls /mnt/cache/sessions/m -l
drwxrwxrwx 2 nobody nogroup 4096 May 16 10:33 0
drwxrwxrwx 2 nobody nogroup 4096 May 16 12:18 1
drwxrwxrwx 2 nobody nogroup 4096 May 16 10:33 2
drwxrwxrwx 2 nobody nogroup 4096 May 16 10:33 3
drwxrwxrwx 2 nobody nogroup 4096 May 16 12:16 4
drwxrwxrwx 2 nobody nogroup 4096 May 16 12:14 5
...

ls /mnt/cache/sessions/m/5 -l
-rw------- 1 nobody nogroup 0 May 16 12:14 sess_m5ifehvhkjdisp7dgtiuu601e2

解决方案

I think I have found the root cause of this issue, which I also ran into when upgrading from PHP 5.5.10 to 5.6.5.

The PHP 5.5.12 changelog lists the following bugfix:

When the session.save_path is a directory that everyone can write into (like on Debian), even if it's not possible to find the IDs of existing sessions, a local attacker can just create a new session file with malicious session data, chmod it to 666 and access any webapp hosted on the system with the session ID he chose. The webapp then opens the session file and treats it as if it had created it. My fix: fstat() the session, check the uid that created the file. If it's neither the result of getuid() nor uid 0, ignore the existing file.

In a nutshell, they stop writing session data if they discover the newly created session file is not owned by the user account running Apache, or root. Which is rather ridiculous, as NFS implements its security at different levels, but is normally deployed with the remote UID/GID mappings, and oft squashed. Thus the Apache user doesn't own the file anymore from the microsecond it has created it. This means that, from PHP 5.5.12 onwards (or 5.4.28 which contains the same 'fix'), it's become impossible to store session data on most stock NFS servers.

这篇关于PHP无法从NFS共享读取会话的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！