The user security model

One hosting account has three system users behind it. Knowing them, and why they're separate, answers most permission questions you'll meet on the server.

User	Identity	What runs as it
you	Your account username, the login user.	The terminal, SSH, cron jobs, app servers, and containers. This user owns your files.
you-www	The web identity.	The web server, and the PHP applications it runs from your document roots, i.e. your direct sites.
you-mail	The mail identity.	Owns the mail storage.

Why the users are separate

The separation limits the damage from an attack, in two directions.

• A compromised website can't take your account. A web application served directly is the most exposed code you run: anybody can reach it, it often comes from a third party, and it isn't always current. It runs as you-www, so an attacker who takes it over can only read and write what you granted through web permissions. Your other sites' code, dotfiles, SSH keys, and cron jobs belong to you, out of reach.
• Neither of those two users can touch the mail. A mailbox holds password resets and private correspondence that belong to other people, your domain users. you-mail owns it, so neither a compromised website nor a program running as your login user can read or change it. You manage mail only through the email pages.

This is why web permissions exist

Your files are private by default. To serve a file, you grant the web user access to it deliberately, in the file manager.

Where the split applies, and where it doesn't

The you-www boundary belongs to direct serving: code the web server runs from a document root.

The other two architectures, app servers and containers, run as your login user. They're programs you chose to run, not files the web server found.

An app server has your full permissions

Inside the account, an app server reaches everything in your home directory, all your databases, and your crontab. Direct serving gives you containment at the cost of flexibility; the other two give you flexibility at the cost of containment.

Run third-party code you don't fully trust as a direct site behind web permissions, or inside a container, where the image boundary gives the containment. Don't run it as an app server script with your whole home directory in reach.

Run a command as the web user

Some commands must run as the web user, usually a maintenance task for a direct site that writes the files the web app also writes. Run it as you and the app can no longer overwrite those files.

wsudo exists for this:

wsudo php ~/public/example.com/maintenance.php

It runs the command as your -www companion user and nothing else: it can't get root and can't reach another account. The task scheduler examples use it too.

Directory layout

The disk shows the same split. Your account's base directory holds three trees:

Directory	Owner	Contents
home/	you	Your home directory: the document roots of your websites (under public/… by default), your application code, and your dotfiles. Your shell starts here, and ~ is this directory.
mail/	you-mail	The mailbox storage. Manage it through the email pages, not directly.
log/	—	Your web server's logs.