feature request: filter shown requests by current domain

[ioweb-gr]

The control panel shows requests for all records it has recorded and does no filtering.

Would it be possible to only show requests that match the current domain?

e.g. I enable spx on domain1.com and domain2.com

When I log in to the control panel I can see requests from both domains.

I would prefer it if I saw only relevant requests first of all for privacy reasons and secondly because it's easier to find the request i want to troubleshoot

[NoiseByNorthwest]

Yes, I can add a basic filtering capability to this table. But, regarding the need to set a default value for a specific filter I'm less sure that it is fair/useful for the common use cases.

[ioweb-gr]

Let me explain why I suggested this in more detail. As I've mentioned before I wanted to try this in an almost real case scenario so I used our development server which uses the same PLESK setup as the production servers for shared hosting.

I've noticed two things happening so far:

All data by default is saved in /tmp/spx folder directly under the name of the first system user that created the folder.

That means that in a clean installation, when I enable the profiler for domain example.com under the system user sys_example with default settings and make a recording the extension will create a subfolder in the (for now) clean /tmp folder called spx.

This spx folder is generated under the owner of the system user for the current domain. So I'd end up with this state

755 sys_example:psacln /tmp/spx

Then I decide to do a profile for example2.com under the system user sys_example2 . Unfortunately I notice that because the user tries to write in the same /tmp/spx folder, he cannot because he doesn't own the folder spx, thus there is no profile generated. And this is the first issue.

The user profiling example2.com sees the data for example.com

It seems even though the profile written to the spx directory belongs to user sys_example the other user still has access to it. So he might see sensitive data from the first user. So when I entered the control panel from example2.com I was able to see all the profiles from example.com

Why is this an issue? Sometimes we want to allow outside companies / freelancers to assist us and they sign an NDA with us according to the GDPR regulation. We're also only allowed to share data our customers allow. So giving access to a third party user like this kind of defeats the purpose as he can potentially see data from other websites.

Current workaround

For our development php versions, we can hardcode the path for each fpm-pool so that each system user uses his own tmp folder in /var/www/vhosts/tmp but he can edit the php settings from the control panel and change it back to /tmp/spx if he wants. Since /tmp has loose permissions he can write to it instead of his own tmp folder.

More security concerns

• I haven't tested what the extension will do if I set the directory to for example /tmp (since I was still trying the profiles). Could he see other user session files potentially? I'm assuming the extension is performing a scandir to list the files existing in the /tmp/spx folder.

And this is how I came up with the idea that the profiles should be isolated by each system_user in the spx folder in the first place.

For example if the structure was like this

/tmp/spx/<system_user>/profiles...

It would potentially eliminate such risks of data leaks by default.

What do you think?

[NoiseByNorthwest]

Thanks for these details. What I can simply say is that php-spx is not a security nor an isolation/sandboxing/jail tool. It is up to you to ensure that your isolated php environments do not leak data via their php-spx's data dir.

In other words I should not add isolation-related features to php-spx because it is definitively not the right place to implement, audit & maintain it. Furthermore isolation is a system-wide concern, a whole sub-system should be best isolated with the same tool / setup.

For instance if you want a full isolation between example.com & example2.com I would say that modern tools & practices tell us that these 2 environments should not only be able to only see their own directory within /tmp but they should also not be able to see the same FS at all, so a full FS isolation, in addition to other isolation level such as process table or network stack.

[ioweb-gr]

True, I agree with you in the matter than nothing is entirely safe unless you go to such lengths but I highly doubt all hosting providers go to these lengths.

I just haven't seen such isolation with cpanel, plesk, virtualmin, directadmin and ispconfig hosting panels. These are the major players in the market though.

For example in godaddy I had shell access and you can actually view other directories in your vhost but you can't really read or manipulate the contents since they belong to the same group but different owner. Permissions handle it to some extend unless you escapeyour jail. In cpanel they've opened bash for us and you can list any folder you know has 777 permissions.

I think what you mention will likely only happen in cloud systems which virtualize everything on each instance or by slicing dedicated hardware to virtual machines which doesn't happen pretty often.

Still even if not for security concerns my suggestion should at least fix the bug with permissions where you can only perform profiling on one single domain unless you delete the entire spx folder because it is created by the system user of the first domain that debugging was enabled at, right? Of course I'd like to hear any ideas to work around this issue.

[NoiseByNorthwest]

For our development php versions, we can hardcode the path for each fpm-pool so that each system user uses his own tmp folder in /var/www/vhosts/tmp

Yes

but he can edit the php settings from the control panel and change it back to /tmp/spx if he wants

I don't get where is the issue as long as other fpm pools still use their own data dir ?

For example if the structure was like this

/tmp/spx/<system_user>/profiles...

It would potentially eliminate such risks of data leaks by default.

What do you think?

It will indeed eliminates a path to a data leak, which is SPX specific, but certainly not all paths, even amongs those specific to SPX. You really need a much wider & simple isolation scheme. Having a bit of isolation provided by SPX about the only identified weakness ATM will just bring a false sense of security IMO. Furthermore, security is a very hard topic for me, with an heavier commitment than other concerns. I'm not ready to support more security-related features, except for the authentication part of the web-UI.