Bug #69582 [Ana]: Sessions are not read from CLI
| From: | rasmus@php.net | Date: | Thu, 11 Jun 2015 20:34:49 +0000 |
| Subject: | Bug #69582 [Ana]: Sessions are not read from CLI | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-193341@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=69582&edit=1
ID: 69582
Updated by: rasmus@php.net
Reported by: me at spinov dot net
Summary: Sessions are not read from CLI
Status: Analyzed
Type: Bug
Package: Session related
Operating System: CentOS 6
PHP Version: 5.4.40
Block user comment: N
Private report: N
New Comment:
So you are probably hitting this check:
https://github.com/php/php-src/blob/PHP-5.4/ext/session/mod_files.c#L190-L196
The file needs to be owned either by root or by the same user id your script is running as to avoid
session hi-hacking. So I don't understand why it wouldn't work as root. The is checking
sbuf.st_uid and it is it 0 it should skip right past that block. But I am also confused. Your
original report said it didn't work as root, but your latest update says, "If I change
owner to root, everything works." That's exactly what I would expect.
Previous Comments:
------------------------------------------------------------------------
[2015-06-11 07:10:16] me at spinov dot net
Also, as you see, in successful call, there is flock(), fcntl64(), pread64() calls, which are not
present in case when session file is not owned by root.
------------------------------------------------------------------------
[2015-06-11 07:04:11] me at spinov dot net
I did that as well, but strace doesn't show anything wrong. Here is part of strace with
commands:
session_id("tsbet8evtiii516f15sk90if87");
session_start();
open("/var/lib/php/session/sess_tsbet8evtiii516f15sk90if87", O_RDWR|O_CREAT|O_N
OFOLLOW, 0600) = 3
fstat64(3, {st_mode=S_IFREG|0600, st_size=34530, ...}) = 0
getuid32() = 0
geteuid32() = 0
close(3) = 0
gettimeofday({1434005695, 403384}, NULL) = 0
gettimeofday({1434005695, 403464}, NULL) = 0
open("/var/lib/php/session/sess_tsbet8evtiii516f15sk90if87", O_RDWR|O_CREAT|O_N
OFOLLOW, 0600) = 3
fstat64(3, {st_mode=S_IFREG|0600, st_size=34530, ...}) = 0
getuid32() = 0
geteuid32() = 0
close(3) = 0
write(2, "PHP Warning: Unknown: Failed to"..., 176PHP Warning: Unknown: Faile
d to write session data (files). Please verify that the current setting of sess
ion.save_path is correct (/var/lib/php/session) in Unknown on line 0
) = 176
Here is file info:
# stat /var/lib/php/session/sess_tsbet8evtiii516f15sk90if87
File: `/var/lib/php/session/sess_tsbet8evtiii516f15sk90if87'
Size: 34530 Blocks: 72 IO Block: 4096 regular file
Device: 801h/2049d Inode: 175886 Links: 1
Access: (0600/-rw-------) Uid: ( 500/silveredge) Gid: ( 500/silveredge)
Access: 2015-06-11 10:53:05.318976435 +0400
Modify: 2015-06-11 10:53:04.417976479 +0400
Change: 2015-06-11 10:53:04.417976479 +0400
If I change owner to root, everything works. Here is strace for that case:
open("/var/lib/php/session/sess_tsbet8evtiii516f15sk90if87", O_RDWR|O_CREAT|O_NOFOLLOW,
0600) = 3
fstat64(3, {st_mode=S_IFREG|0600, st_size=34530, ...}) = 0
flock(3, LOCK_EX) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fstat64(3, {st_mode=S_IFREG|0600, st_size=34530, ...}) = 0
pread64(3, "user-admin|a:11:{s:2:\"id\";i:5;s:"..., 34530, 0) = 34530
mmap2(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb699e000
gettimeofday({1434006320, 576258}, NULL) = 0
gettimeofday({1434006320, 576348}, NULL) = 0
pwrite64(3, "user-admin|a:11:{s:2:\"id\";i:5;s:"..., 34530, 0) = 34530
close(3) = 0
As you see, it looks a bit differently than previous one, cause file is not opened twice. But open
call is the same with same result.
------------------------------------------------------------------------
[2015-06-11 06:45:00] rasmus@php.net
This doesn't sound like a PHP issue. Run:
strace -o out.txt php your_script.php
And look through out.txt and and find where it tries to open the session file. That should give you
a hint as to what could be wrong.
------------------------------------------------------------------------
[2015-06-11 06:29:31] me at spinov dot net
SELinux is disabled by config on boot. So it's not SELinux.
# getenforce
Disabled
I've also tried 5.5, 5.6 branches. Issue persists. If I rollback to 5.3 - everything works.
------------------------------------------------------------------------
[2015-06-11 01:53:21] yohgaki@php.net
I cannot reproduce by PHP-5.4 branch's PHP.
Sounds like you have selinux problem. Try
sudo setenforce 0
see if this helps.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=69582
--
Edit this bug report at https://bugs.php.net/bug.php?id=69582&edit=1