Files

How it works

The panel does not read files as root and hand them down. It starts a klyrn files-helper subprocess running as the account's Unix user, and that process does the work. A path the account cannot reach, the helper cannot reach either: the kernel decides, not KLYRN's own path checks.

Uploads and downloads pass through a staging directory that only the panel user can write into and only root can list, and core accepts a staged file only if it is a regular, non-symlink file directly inside that directory and owned by the panel user. The helper has a ten-minute ceiling.

Inside the account, user-supplied paths are resolved with openat2 and RESOLVE_BENEATH, so ../ and a symlink out of the tree both fail in the kernel rather than in a string comparison.

What you can do

Browse and read

List a directory, open a file in the editor.

Write

Save an edited file, create a directory.

Rename, delete, chmod

The ordinary operations, on one entry or a selection.

Upload and download

Through the staging handshake above. Downloads are recorded in the audit log.

Copy and move

Whole trees. A symlink inside the tree is refused rather than followed, and free space is checked first.

Compress and extract

Create an archive from a selection, or unpack one.

Every one of those is a typed operation with its own validator and its own audit entry. None of them takes a command string, so there is no place for a shell to be involved.

When the account is over its limit

Four of these grow the account: upload, extract, copy and compress. Those are refused when the account is over its disk limit, with the limit, the usage and the age of the measurement in the message.

Delete, rename, chmod, write and mkdir keep working. Deleting is the way back under the limit, and an account that cannot edit .htaccess or wp-config.php to fix its own site because it is 2 MB over is a support ticket, not enforcement.

A refusal also schedules a fresh measurement, so "delete some files and try again" works within about a minute rather than at the next quarter hour. See Resource limits.

.htaccess

nginx does not read .htaccess, and KLYRN does not pretend it does. A file left behind by a migration is inert.

What KLYRN does instead: it reads the file, translates the rules it understands into the site's nginx configuration, and shows you the translation before applying it. Rules it cannot translate are listed rather than dropped silently. See Migration.