Bug #69582 [Ana]: Sessions are not read from CLI

From: 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

« previous php.bugs (#193839) next »