How Roles and Permissions Work Inside tiCrypt Virtual Machines
- VM permissions are set per VM and take precedence over your system permissions. Inside a VM, the VM's grant is what decides
- VM roles (Owner, Co-owner, Manager, User) are independent from system roles. An Admin has zero VM access unless explicitly granted
- The VM Owner is whoever started the VM; they control all access to drives and data inside it
- Co-owners can be given the Owner's drive keys; Managers can be granted the Drives permission but hold no drive keys; Users have the least privilege
- Jump to the permission details for the full comparison
This page covers roles inside a virtual machine. For system-wide roles (User, Sub-Admin, Admin, Super-Admin), see User Roles. For how institutional personas (PI, Lab Manager, etc.) map to tiCrypt roles, see Institutional Role Mapping.
In most platforms, being an administrator means having access to everything: every file, every machine, every user's data. tiCrypt is built on the opposite principle. A system-wide admin has no access to any virtual machine, its drives, or the data inside them unless the VM Owner explicitly grants it. The person who starts the VM is in control.
VM roles and permissions operate as a completely independent system from the main tiCrypt role hierarchy.
On a traditional shared computing cluster, system administrators have root access to every node and every user's data. In tiCrypt, system administrators manage infrastructure but cannot access any VM, its drives, or the data inside them. The VM Owner controls access. This is the most significant mental model change for shared computing cluster users. See From Shared Computing Cluster to tiCrypt for a full concept mapping.
Why VM Permissions Are Separate
tiCrypt enforces separation of duties at an architectural level. The main system handles user accounts, team membership, projects, and vault-level file encryption. VMs host research environments: operating systems, applications, attached drives, and live user sessions.
These are distinct trust domains. A main-system admin can manage teams, activate user accounts, and configure hardware setups. They cannot open a VM terminal, read its drives, or manage its users. A VM Owner, on the other hand, has full authority over their VM but cannot promote users, change system settings, or access another user's Vault. Neither role inherits the other's capabilities.
Permissions are held per VM, and inside a VM they take precedence. Each machine carries its own permission set, granted by that machine's Owner. While you are working inside it, that set governs what you can do, and it overrides whatever permissions your system role carries. This is the mechanism behind the separation described above: an Admin has no access to a VM not because the system withholds it as a special case, but because system permissions do not apply inside a VM. The same machine can grant you one set of capabilities and grant a colleague another, and neither is affected by what either of you can do in the main system.
The key principle: access to a VM is explicitly granted by the VM Owner. It is never inherited from the main system.
This means a regular user in the main system can be the Owner of a VM with full authority over it, while a Super-Admin may have zero access to that same VM. Neither role implies the other.
How a VM Gets Its Owner
To understand roles inside a VM, it helps to understand how a VM comes into existence.
A VM is launched from a VM Config, a template that holds the owning team, an optional project, the owners (the creator and any Co-owners), the home drive, any extra drives with their slot and read-only or read-write access, and optionally a MAC address and a preferred host, together with the hardware setup, which includes the image. The VM Config is the blueprint; the running VM is an instance of it. The user who starts the VM becomes the Owner, and that role bootstraps the entire VM user management system.
Once the VM is running, the Owner can add users, assign roles, and configure permissions. Users who were previously added to the VM retain their roles and permissions across restarts, because that information is stored in a database on the VM's home drive (the first attached drive).
If a home drive is detached from one VM Config and attached as the home drive of another, the VM user database travels with it. The new VM inherits the users, roles, and permissions from the drive. This only applies when the drive is the first attached drive. Attaching it as an additional drive does not import its user database.
All Co-owners listed in the VM Config are added to the running VM with the Co-owner role, but only the user who actually starts the VM becomes the Owner.
The Role Hierarchy
VM roles form a hierarchy. From lowest to highest: User, Manager, Co-owner, and Owner. Users can only modify other users with a role lower than their own.
Owner & Co-owners
The Owner has unrestricted authority over the VM. They can:
- Add, remove, and manage all users in the VM
- Assign and revoke any role or permission
- Manage groups, drives, and access directories
- Connect to the VM via RDP/VDI
- Transfer files between the VM and the Vault (subject to main-system permissions)
- Shut down the VM
There is exactly one Owner per running VM: the user who started it from the VM Config.
Co-owners are defined in the VM Config and receive their role automatically when the VM starts. With the drive keys, they can also restart the VM and mount its drives in other VMs. If a Co-owner restarts the VM, they become the Owner for that session and the previous Owner reverts to Co-owner.
Drive keys are not part of the Co-owner role itself. A Co-owner holds a key to a drive only when someone who already holds that key shares it with them. tiCrypt shares the keys of the configuration's drives with Co-owners when:
- A Co-owner is added: through Add co-owners on the configuration, or with the Co-owner role in Add users on the running VM. The person adding them must hold the keys (read-write keys for drives the configuration attaches read-write) and the system permissions Get drive keys (needed to share and attach drives) and Share drives.
- A configuration with Co-owners is saved: if some Co-owners lack keys, a prompt offers to share them, and its Share and save button saves the configuration and shares the keys.
- A drive is formatted for the first time: the new key is shared with the configuration's Co-owners.
- The Owner repairs missing keys: when Co-owners lack keys, the Owner of the running VM sees a Repair prompt that shares the configuration's drive keys with every Co-owner.
Keys can also be taken away: when a Co-owner is removed, the person removing them can revoke their keys to the drives they own.
When a user is added as a Co-owner, the keys you hold to the VM's associated drives are shared with them. Co-owners need drive access to manage the VM, so grant Co-owner status only to trusted users.
Manager
Managers sit between the Owner or Co-owners and regular Users. They can perform management tasks within the VM, but only to the extent that the Owner has granted them specific permissions.
A Manager can:
- Add and manage users with a lower role
- Manage VM groups and access directories (if permitted)
- Connect to the VM and perform research
- List, format, mount, and unmount drives (if granted the Drives permission). The Manager role does not come with drive keys.
User
The User role provides access to the VM for research purposes, through an RDP or VDI interface. Users can interact with data and applications inside the VM, but their actual access is governed by their membership in VM groups and the configuration of access directories.
Users have no management abilities. They cannot access the VM management interface, manage other users, create groups, or modify drive configurations.
Permissions Within a VM
Roles establish the hierarchy, but permissions determine what a user can actually do. Each user in a VM has a set of granular permissions that the Owner or a Manager can configure individually.
Permissions cover several areas:
| Permission Area | Controls |
|---|---|
| Users | Viewing other VM users; for managers, also creating, deleting, and modifying them |
| Files | Viewing, previewing, and editing files; for managers, also deleting files and directories |
| VM to Vault transfer | Transferring files from the VM to the tiCrypt Vault |
| Vault to VM transfer | Uploading files to the VM and creating directories |
| Terminals | Opening terminals through tiCrypt; for managers, also interacting with other users' terminals |
| Remote application access | Accessing VM applications, such as the remote desktop, from the user's desktop |
| Access Directories | Viewing access directories; for managers, also creating, deleting, and modifying them |
| Groups | Viewing VM groups; for managers, also creating, deleting, and modifying them |
| System Statistics | Viewing real-time system utilization |
| SFTP Access | Connecting to the VM via SFTP |
| Drives (managers only) | Listing, formatting, mounting, and unmounting drives |
| Full drive access (managers only) | Owner-like manager permissions |
| Restart VM controller (managers only) | Restarting the VM controller to update it or fix issues |
| Sudo (Admin) Access (managers only) | Granting administrator privileges inside the VM |
| Manage VPN (managers only, constellation VMs) | Managing the VPN |
| VM Orchestrator (managers only, constellation VMs) | Managing the constellation |
Permissions are assigned per user and can be customized regardless of role. A Manager with only the Remote application access permission, for example, can connect to the VM but cannot list drives or manage groups. The Owner retains full control over which permissions each user receives.
Where Main-System and VM Permissions Intersect
While VM and main-system permissions are separate, certain operations require both. The clearest example is file transfer.
If a user is the VM Owner and has full permissions within the VM, they can initiate a file transfer to the Vault. But if that same user lacks the main-system permission to write files in the Vault, the transfer will fail. The VM grants the ability to initiate the transfer; the main system gates whether it completes.
Similarly, starting a VM requires main-system permissions to spawn VMs and to access the relevant drive keys. Once the VM is running, control shifts to the VM's own permission system.
The rule of thumb: VM permissions govern what happens inside the VM. Main-system permissions govern everything outside it. Operations that cross the boundary require both.
System Admin vs. VM Owner
This is where tiCrypt's separation of duties is most visible:
| Action | System Admin | VM Owner |
|---|---|---|
| Configure VM hardware setups and images | Yes | No |
| Manage VM host infrastructure | Yes | No |
| Shut down a VM | Yes | Yes |
| Start a VM | Requires drive key access | Yes |
| Connect to a VM | Only if explicitly granted access | Yes |
| Manage VM users | No | Yes |
| Access data on VM drives | No | Yes |
| View VM audit logs | Yes (with permission) | No |
System admins can manage the infrastructure that VMs run on, but they cannot reach into a running VM. They can shut down a VM in an emergency, but they cannot connect to it, manage its users, or read its drives unless the VM Owner has explicitly granted them access.
In compliance-sensitive environments (CMMC, NIST 800-171, ITAR, HIPAA), administrators must be able to prove they cannot access research data. tiCrypt enforces this through VM ownership and drive-key access rather than through policy alone.