For my Joomla! 3.8+ extension I need to be able to find and delete (unlink) PHP session files (named 'sess\_' + session id) which will be stored in the session\_save\_path, e.g. /tmp. I understand that it is PHP who is storing the session files, i.e. not Joomla! (Joomla! session handler set to 'PHP')
My question: Will a PHP session file that is created through the use of the Joomla! website ALWAYS be read/write accessible by my extension's PHP code which is part of the same Joomla! install?

**Addition: I realised later, that I omitted the word 'always' in my question, which I have now added.**

**Addition: More in-depth explanation about what I am trying to achieve.**
As I said I have a Joomla! site, where users can log into.
The issue applies ONLY when Joomla! is configured with Session Handler set to 'PHP' (instead of 'database'). When Session Handler is 'database', there is no problem.

In basic terms, I want to achieve the following (with Joomla! session handler set to 'PHP'):

> 
> 1> A user opens browser A and logs into the website and Joomla!
>  records the related session ID plus user ID in a database.
> 
> 
> 2> The same user opens a different browser B (maybe at a different IP)
>  and wants to log into the same website.
> 
> 
> 3> Because user has already logged into the website through browser A,
>  he/she is not allowed to log in again and will be presented a
>  clickable link that will destroy all his other sessions, including the
>  one with browser A (we have recorded the session IDs of all the other
>  sessions).
> 
> 
> 

A mere session\_destroy() in step 3 is just partly doing the trick, because the destroyed session details reappears after a little while at the Joomla! backend and also in the Joomla! session table. Although this does not interfere with the Joomla! front-end, it is not clean and I want to avoid it, to make it fool proof.
By far the best solution is if I could delete the PHP session file (for example in dir /tmp and named 'sess\_....'). I have tested this and it worked fine. However... it relies upon always having delete access to the PHP session file (using session\_save\_path() and unlink($session\_file\_path)) and this is the basis of the question that I posted.
I found out that the delete of the PHP session file is not always possible; it depends on the providor's PHP config. Since it is a commercial app that I am developing, the process must work on all configs, i.e. including those that do not allow delete access to the session file.

I will continue my search for a solution and will post it here when I found it.