PHP cannot read sessions from NFS share

Question

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

Answer 1

When using the idmapd service, all mappings are performed by first finding a username/groupname via /etc/nsswitch.conf. If your NFS machines do not actually have username/groupname accessible, idmapd will not complete the mapping.

In this case it appears that you will need a www-data user on both the NFS client machine and the NFS server. If you would rather not edit local /etc/passwd /etc/group files to ensure bother servers have an entry for www-data, you can configure ldap or nis systems to manage user/group domains via /etc/nsswitch.conf.

See my long winded answer here.

Answer 2

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.