Category: Security / System Users

Summary

When Ploi provisions a system user per website (the current segmentation model), that user is still able to list /home/*, read the full Ubuntu login banner including the server's IP address, kernel version, memory/CPU usage and other metadata, and navigate freely outside their own directory. On a shared server hosting multiple clients, this is a meaningful information disclosure risk. We'd like Ploi to implement a set of industry-standard hardening measures as part of the system user provisioning flow.

Current workaround

We've manually applied chmod 711 /home which prevents listing of other users' directories. This is the minimum viable fix but it's not automated, not comprehensive, and requires server admins to know to apply it.

Requested improvements

1. Filesystem isolation (standard on all reputable shared hosts)

• Set chmod 711 /home as the default on new servers (or during Ploi's provisioning)
• Set chmod 700 on each individual /home/<siteuser> directory so no user can traverse into another's home
• These two together are the well-established baseline for shared hosting user isolation (cPanel, Plesk, and DirectAdmin all do this by default)

2. Clean, context-aware login banner

The default Ubuntu MOTD exposes:

• Public IP address
• Kernel version and architecture (fingerprinting risk)
• Memory, swap, CPU load (reveals server capacity to users)
• Number of currently logged-in users (reveals concurrent session count)
• ESM/package update status

This information is irrelevant to a website system user and only useful to an attacker. We'd like Ploi to:

• Disable the default Ubuntu MOTD scripts (/etc/update-motd.d/) for SSH sessions belonging to system users
• Inject a minimal, per-user banner via ~/.profile or /etc/profile.d/ that shows only site-relevant info:

Domain         example-site.com
System user    examplesite-xkqmr
Server path    /home/examplesite-xkqmr/example-site.com
Public path    /home/examplesite-xkqmr/example-site.com/public
PHP version    8.4

This is comparable to what cPanel and Plesk show on SSH login — clean, helpful, no metadata leakage.

3. Restricted shell / command scope (optional toggle)

For servers where SSH is offered to end-clients rather than internal devs, consider offering an option to assign rbash (restricted bash) as the login shell. This prevents:

• cd to absolute paths outside the home directory
• Execution of commands that enumerate other users (w, who, last, ps aux, netstat, ss)
• PATH manipulation

An advanced option could support jailkit or firejail chroot-based SSH isolation.

4. Maintain log file access via ACLs (important nuance)

Site logs like /var/log/nginx/example-site.com-error.log are owned by root/www-data and must remain accessible to the system user. The solution is not to make /var/log/ world-readable, but to use POSIX ACLs at provisioning time:

setfacl -m u:<siteuser>:r /var/log/nginx/example-site.com-access.log
setfacl -m u:<siteuser>:r /var/log/nginx/example-site.com-error.log

This should be done automatically when Ploi creates a new site, not left as a manual task.

Why this matters

Shared hosting isolation is a well-understood problem. The industry best practices (filesystem permissions, MOTD suppression, restricted shells, targeted ACLs) have been established by cPanel, Plesk, and DirectAdmin for over 15 years. As Ploi positions itself as a modern alternative for agencies and hosting providers, baking these measures into the provisioning pipeline — rather than leaving them as undocumented post-install steps — would be a meaningful differentiator and a genuine security improvement for all multi-tenant Ploi servers.

Impact

Affects any Ploi server that hosts multiple clients with individual system users and offers SSH access (SFTP or full shell). Low implementation effort for Ploi, high security value for the ecosystem.