Bug #69582 [Ana]: Sessions are not read from CLI
| From: | yohgaki@php.net | Date: | Wed, 24 Jun 2015 12:50:44 +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-193839@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: yohgaki@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:
It may be better to update/add error message.
I think Stas' point is "only allow access root created session data when root is the
user".
If you have root access, you can do 'su - user -s /bin/bash' to access the user's
session file. Accessing by different user could cause problems like creating root owned session data
files.
CLI has builtin web server also. We should be careful.
Just my thought for now.
Previous Comments:
------------------------------------------------------------------------
[2015-06-24 11:47:17] me at spinov dot net
Added 4 Pull Requests for branches 5.4, 5.5, 5.6, master.
------------------------------------------------------------------------
[2015-06-14 07:38:54] me at spinov dot net
Ok, just to clarify root/not-root stuff:
- When session file is owned by non-root, and process is owned by root, it doesn't work ( first
strace ).
- When session file is owned by root ( this is my phrase "If I change owner to root, everything
works." ) and process is owned by root - everything works. ( second strace ).
Sorry if I confused you here.
Now with regards to your comment about hi-jacking: I believe it should be OS driven ( like in PHP
5.3 ): if OS allows to read session - PHP reads it. In case file is owned by UID #1 and I'm
trying to access it with UID #2 - it will fail on OS level, cause session file is with 600
permission.
In my case - root can read the file on OS level, but PHP is not allowing it to do that. It
doesn't make any sense, as I can still hi-jack session by changing ownership of session file (
as I'm root ). And I'm actually doing this workaround: chown-to-root(), read-session(),
chown-back().
So the line you've referred seems to be the case as condition is true for session file owned by
non-root and process owned by root.
Probably this condition should be added with clause process owner is root. Cause you do have this
for a file (sbuf.st_uid != 0)
------------------------------------------------------------------------
[2015-06-11 20:34:47] rasmus@php.net
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.
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
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