Run content as the current user
This guide walks through configuring Posit Connect so that interactive content runs as the current user: under the Unix account of the person viewing it, rather than under a single shared service account.
The main reason to run content as the current user is to control access to data on a shared filesystem. Because each process runs under the viewer’s own Unix account, it reads and writes files as that person, so you can govern which data each user can access with standard Unix filesystem permissions. Connect supports current user execution for interactive applications, such as Shiny and Streamlit apps, and for APIs, such as Plumber, Flask, FastAPI, and Node.js. It is not available for static content.
Background
By default, Connect runs all content under a single shared Unix account (rstudio-connect). Every process reads and writes files as that one account, so on a shared filesystem all content has the same access to data, no matter who is viewing it. This is the recommended configuration for most installations.
Current user execution changes this. When a user opens an interactive application, Connect launches the process under the Unix account associated with that user. The application then reads and writes files as that specific person, so you can use standard Unix filesystem permissions, such as user and group ownership and mode bits, to control which data each user can access on a shared filesystem.
Current user execution governs identity, not process isolation. Connect already isolates content processes from one another regardless of which Unix account they run as, through sandboxing on local execution and through container isolation in off-host (Kubernetes) deployments. Use current user execution when you need the operating system to enforce per-user data access, not to separate processes.
This identity model has a cost. Under the shared account, Connect can serve many viewers of an application from a single process. Because each viewer’s process runs under a different Unix account, current user execution removes that sharing: every concurrent viewer spawns a dedicated process. An application’s process count, and its memory and CPU use, then grow with the size of its audience. Plan capacity for the number of concurrent viewers rather than the number of connections, review the application’s process settings, and see Sizing and capacity planning for guidance.
Connect maps a logged-in user to a Unix account through the Connect Nameservice, which bridges the operating system and your federated authentication provider: OAuth 2.0, Security Assertion Markup Language (SAML), or Lightweight Directory Access Protocol (LDAP). You can also configure current user execution with Pluggable Authentication Modules (PAM), which does not require the nameservice.
Alternatives to current user execution
Current user execution adds operational complexity and increases resource usage. Before adopting it, compare the approaches below to decide which one fits your needs:
| Approach | Use it to | Server processes |
|---|---|---|
| Current user execution | Control access to data on a shared filesystem using Unix permissions. | Each concurrent viewer runs in a dedicated process under their own Unix account. Connect cannot share a process across viewers, so process count and resource use grow with the audience. |
| OAuth integration | Authorize downstream data access (databases, APIs, cloud services) per viewer, without changing the Unix account the process runs as. | Shared. A single process can serve many viewers, up to its configured maximum connections per process. |
Per-content RunAs user |
Run specific content under a specific, non-default Unix account. Assign different accounts to different content to model group-based data access with Unix group permissions, without per-viewer execution. | Shared. A single process can serve many viewers. |
Shared rstudio-connect account (default) |
Keep the recommended default. No configuration required. | Shared. A single process can serve many viewers. |
If your only requirement is that content authenticates to an external system as the viewer, an OAuth integration is usually the better choice, and it avoids the per-user process overhead. Reach for current user execution when you need to control access to data on a shared filesystem using Unix permissions, and you have accounted for its effect on server resources.
Prerequisites
Before you begin, you must have:
- A Connect Enhanced or Advanced license.
- A Connect installation that uses OAuth 2.0, SAML, or LDAP authentication, or, for local execution only, PAM authentication. Off-host (Kubernetes) execution requires the nameservice with OAuth 2.0, SAML, or LDAP; PAM is not supported. Current user execution does not support Proxied or Password authentication.
- Administrator access to the Connect server and its configuration file.
- The ability to manage Unix accounts and group membership on the Connect server (or, for off-host execution, in your container images).
Step 1: Set up the Connect Nameservice
The nameservice lets Connect resolve each logged-in user to a Unix account. If you authenticate with OAuth 2.0, SAML, or LDAP, install and configure it by following the Connect Nameservice guide, which covers both local and off-host (Kubernetes) execution, user mapping options, and verification.
If you authenticate with PAM, skip this step; PAM does not use the nameservice. PAM is supported for local execution only, not for off-host (Kubernetes) execution. See PAM sessions in the Admin Guide for the PAM-specific setup, including credential caching for Kerberos.
Step 2: Allow current user execution on the server
Set Applications.RunAsCurrentUser to true in the Connect configuration file:
/etc/rstudio-connect/rstudio-connect.gcfg
[Applications]
RunAsCurrentUser = trueRestart Connect to apply the change.
This setting permits current user execution but does not change how any existing content runs. You must still configure each application individually to request it, as described in Step 4. Content you have not configured for current user execution continues to run as the RunAs user.
Step 3: Confirm Unix accounts have the required group membership
Every Unix account used to run content must belong to the group named by Applications.SharedRunAsUnixGroup. This applies to each viewer’s Unix account, not only the default service account. An application fails to launch if the account associated with the logged-in user is not a member of this group.
How you satisfy this depends on how the Unix account is created:
- Accounts the nameservice provisions automatically: The nameservice sets each new account’s group to
Applications.SharedRunAsUnixGroup, so membership is handled for you. No action is needed. - Existing accounts you map through the nameservice, or accounts used with PAM: You must add each account to the
Applications.SharedRunAsUnixGroupgroup yourself.
When you use the default RunAs user, the relevant group is rstudio-connect.
Step 4: Configure content to run as the current user
By default, only administrators can change process execution. Publishers can set it for content they own or collaborate on when Authorization.PublishersCanManageRunAs is true.
In the Connect dashboard, set the content’s process owner to the current user. For the steps and the full set of options, see Changing the process owner in the User Guide.
You can also configure this programmatically. The run_as_current_user field on the create and update content API endpoints toggles current user execution for a content item.
When someone accesses the content anonymously, it runs as the configured fallback RunAs user instead of a per-user account.
File permissions considerations
Because each viewer’s process runs under a different Unix account, another user who opens the same application might not be able to read files that the first user wrote to the working directory. A file with restrictive permissions, such as mode 0400, can cause failures for other viewers.
All accounts used for current user execution share membership in Applications.SharedRunAsUnixGroup, so set group-readable permissions explicitly on any files your application writes and needs to share. For details and recommendations, see Writing data to the working directory.