Distinguish panel roles from process identities
An AdaPanel customer or reseller role concerns actions available through the management interface. A web application’s file access is evaluated through its Windows process identity and filesystem permissions. Keep these as separate acceptance criteria.
Separate pools help establish process separation, but are not a virtual-machine security boundary. Sites can still share an operating system, administrators and services. Choose the required separation level according to application and customer data risk.
Build a least-privilege access matrix
| Resource | Site A identity | Site B identity |
|---|---|---|
| Site A code | Required read/execute | No access unless explicitly needed |
| Site A uploads | Required writes; prevent code execution | No access unless explicitly needed |
| Site B files | No access unless explicitly needed | Permissions needed by its application |
| Backups and private keys | Limited to a defined operational need | Limited to a defined operational need |
Inspect an existing server safely
- Map site to pool, process identity and physical directory.
- Inspect direct and inherited permissions, including access granted through shared groups.
- Check database, FTP, scheduled-task and external storage identities against the same customer boundary.
- Prepare an ACL backup and application acceptance checks before changing permissions; do not blindly remove inherited access.
Prove the boundary with harmless fixtures
Under controlled conditions, verify that a site identity can read its own files, write to its designated directory and cannot read another customer’s test file. Use harmless markers rather than exposing actual customer secrets in diagnostic output.
An application unable to read its own files is also a failed result. Test legitimate operations and denied cross-customer access together. A successful test for one customer does not establish correct permissions for every account.
Preserve isolation through change
Apply the matrix to new-site templates, migrations and restore procedures. Permissions imported from another server or a shared service account can weaken an originally sound boundary.
For agency handover, record which accounts can access which resources. When staff leave, review FTP, database and task accounts as well as panel access. A tested permission map is more useful than a user list alone.
When testing customer roles, verify that a request for another customer’s resource is denied. A hidden interface link does not establish server-side authorization.
Frequently asked questions
Does a separate panel account prove filesystem isolation?
No. Panel authorization, Windows process identities and NTFS permissions are distinct layers that need separate validation.
Is one application pool per site enough?
It helps, but broad shared folder or database permissions can bypass the intended separation. Check files, data and background tasks too.
Should I grant Everyone write access to resolve errors?
Identify the effective application identity and the narrow writable location it needs instead. Test functionality and isolation after the correction.
Do restored sites need another permission review?
Yes. Identities and inherited permissions can differ on the destination server. Repeat the access matrix tests after restoration.