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

Edit report at https://bugs.php.net/bug.php?id=69582&edit=1 ID: 69582 Comment by: cpuidle at gmx dot de 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: +1 for fixing this. Daemon task running as root fails updating the session (php 5.4, 5.6) on debian. Currently stops me from upgrading our platform. Is there any progress on the PRs? Previous Comments: ------------------------------------------------------------------------ [2015-06-24 13:09:39] me at spinov dot net As for me, everything is pretty simple: if session will be created by root and then accessed by non-root user - this condition will stop script execution with error about reading/writing session data. Regarding warning message or something with respect to current issue - there is nothing wrong happens: root accesses session of non-root on the host. Use case: session is created by Apache ( non-root ), but later on accessed by backend service, that is running under root, due to requirement to execute root commands. I cannot allow Apache to be root user, cause this is insecure. So what options do I have in case of updated/added message? Speaking more globally: I'm not sure if it is correct to override OS permissions. Cause in current edition of that condition there will be issue with accessing session data for groups. It is pretty rare situation, but probably somebody has use case for it. So I would fix this even in more radical way: if user that is running the script can read/write to session file he is requesting, on OS level - let him access it. Cause this limitation doesn't help with hi-jacking in any way as could be easily overriden. And I believe this is the reason this condition was initially added as per comment. ------------------------------------------------------------------------ [2015-06-24 12:50:43] yohgaki@php.net 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. ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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