You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think it's more a feature than a bug, but I didn't fully understand how Tracy worked before running into this problem. And it's very problematic for the deployments of my app .... Since Tracy needs, implicitly very specific privileges.
Brace yourself, we'll talk about sessions here.
Here's the idea :
1 - the acces rights of the session folder
In the folder /var/lib/php/sessions where tracy stores its sessions files
Here find an ls -la of its content, for you to get my problem.
root@my-docker:/var/www/html# ls -la /var/lib/php/sessions
total 28
drwx-wx-wt 1 root root 4096 Mar 24 13:01 .
drwxr-xr-x 1 root root 4096 Jun 2 2021 ..
-rw------- 1 www-data www-data 83 Mar 24 11:07 sess_l9q9be5pija67e0criirm548ut
-rw-r--r-- 1 www-data www-data 6 Mar 24 11:10 tracy-aef1133a02
-rw-r--r-- 1 www-data www-data 41 Mar 24 11:07 tracy-afea481a37
-rw-r--r-- 1 www-data www-data 23 Mar 24 13:01 tracy-c2f9802a62
-rw-r--r-- 1 www-data www-data 23 Mar 24 13:01 tracy-ddce050766
My app is connected as www-data.
2 - the FileSession.php class
I understood that this class handle the session file. Moreover the clean() function allows Tracy to delete its sessions files. OK
3 - The problem with my environment
On the example above I listed only 4 "tracy-" sessions files but after few hours (since I check the 'heartbeat' of my test servers by calling the index) I can end up with thousands of useless tracy files.
The problem with the function glob is that you need to have access rights on the folder sessions as it needs to list all files in the folder. But you can see up there with my ls -la that my folder has very limited rights. (i.e. I can't list the files in the folder but I can delete them if I know the precise filenames.)
4 - Possible improvement
Usually a normal development environment never connects as root, so it may be problematic for devs like me.
I don't have the rights to list all files but I can delete/modify files as long as I know their names.
Here's the idea : add an attribute to FileSession typed string[] to list all the session files created to unlink all the name listed in this variable, instead of using glob.
This feature would be consistent with the way session_destroy() works.
Php lists all the created file like a zval then deletes them by listing all the registered names instead of listing all the session file names from the folder.
The text was updated successfully, but these errors were encountered:
Proposed FileSession::$sessionNames = [] cannot work - once a request is finished, session name is lost. That's why glob() is used to find previous requests sessions.
Why do you enable Tracy (development mode) for heartbeat checks? If you perform heartbeat, you usually want to know that app is OK in a production mode. And in the production mode, Tracy does not start sessions.
Using common /var/lib/php/sessions is tricky. There are system cron tasks or systemd timers (at least on Debian) which tries to clean-up orphaned session files according to session live time set in php.ini. It may delete active long-term sessions. I always keep sessions in application specific directory (like /var/www/sites/example.com/sessions). In that case permissions can more permissive.
Or maybe - you can set ACL for www-data on session dir: setfacl -m u:www-data:rwx /var/lib/php/sessions
DISCLAIMER : I'm aware of this ticket about setting up a custom sessionfile but my suggestion is quite different.
I think it's more a feature than a bug, but I didn't fully understand how Tracy worked before running into this problem. And it's very problematic for the deployments of my app .... Since Tracy needs, implicitly very specific privileges.
Brace yourself, we'll talk about sessions here.
Here's the idea :
1 - the acces rights of the session folder
In the folder
/var/lib/php/sessions
where tracy stores its sessions filesHere find an
ls -la
of its content, for you to get my problem.root@my-docker:/var/www/html# ls -la /var/lib/php/sessions total 28 drwx-wx-wt 1 root root 4096 Mar 24 13:01 . drwxr-xr-x 1 root root 4096 Jun 2 2021 .. -rw------- 1 www-data www-data 83 Mar 24 11:07 sess_l9q9be5pija67e0criirm548ut -rw-r--r-- 1 www-data www-data 6 Mar 24 11:10 tracy-aef1133a02 -rw-r--r-- 1 www-data www-data 41 Mar 24 11:07 tracy-afea481a37 -rw-r--r-- 1 www-data www-data 23 Mar 24 13:01 tracy-c2f9802a62 -rw-r--r-- 1 www-data www-data 23 Mar 24 13:01 tracy-ddce050766
My app is connected as
www-data
.2 - the FileSession.php class
I understood that this class handle the session file. Moreover the
clean()
function allows Tracy to delete its sessions files. OK3 - The problem with my environment
On the example above I listed only 4 "tracy-" sessions files but after few hours (since I check the 'heartbeat' of my test servers by calling the index) I can end up with thousands of useless tracy files.
The incriminated line is here officer :
tracy/src/Tracy/Session/FileSession.php
Line 84 in e4dd63c
The problem with the function
glob
is that you need to have access rights on the foldersessions
as it needs to list all files in the folder. But you can see up there with myls -la
that my folder has very limited rights. (i.e. I can't list the files in the folder but I can delete them if I know the precise filenames.)4 - Possible improvement
Usually a normal development environment never connects as root, so it may be problematic for devs like me.
I don't have the rights to list all files but I can delete/modify files as long as I know their names.
Here's the idea : add an attribute to
FileSession
typedstring[]
to list all the session files created to unlink all the name listed in this variable, instead of usingglob
.This feature would be consistent with the way
session_destroy()
works.Php lists all the created file like a
zval
then deletes them by listing all the registered names instead of listing all the session file names from the folder.The text was updated successfully, but these errors were encountered: