Server Permissions

Server account

Posit Workbench runs as the system root user during startup and then drops this privilege and runs as a more restricted user. Workbench then re-assumes root privilege for a brief instant when creating sessions on behalf of users (the server needs to call setresuid when creating a session, and this call requires root privilege).

The user account that Workbench runs under in the normal course of operations is rstudio-server. This account is automatically added to the system during installation and is created as a system rather than end user account (i.e. the --system flag is passed to useradd).

When Workbench runs with privileges, it performs authentication, provisions PAM sessions, then runs all user code without privilege just like a normal terminal session for that user. When configured for local session launching, these sessions run in multi-user mode on the same server. With Job Launcher session and the Kubernetes plugin, each session runs in it’s own pod for further isolation. With some additional setup, Kubernetes sessions may also be launched directly using the user-id and group ids of the container user, eliminating the need for a privileged launcher to start sessions.

Alternate server account

You can configure Workbench so that it will run from an alternate account with the following steps:

Create a new system user (if the one you want to use doesn’t already exist)
Assign this user to the server-user option in the /etc/rstudio/rserver.conf configuration file (see example below)
Restart Workbench

For example, to shutdown the server and create a new system user named rs-user you’d use the following commands:

sudo rstudio-server stop
sudo useradd --system rs-user

Then edit the /etc/rstudio/rserver.conf configuration file as follows:

/etc/rstudio/rserver.conf

server-user=rs-user

Finally, restart the Workbench server process to begin running under the new user:

sudo rstudio-server start

umask

By default, Workbench sets its umask to 022 on startup. If you don’t want this behavior, for instance because you’d prefer the server process to use the default umask set in init, it can be disabled as follows:

/etc/rstudio/rserver.conf

server-set-umask=0

Running without permissions

Workbench can run in single user mode. This is primarily useful when it is a requirement to run entirely without root privilege; privilege is required to authenticate and run code on behalf of arbitrary users as noted above, but if only a single user will access the server and they have already been authenticated via other means, root privilege is not necessary.

Use a configuration like the following to run in single user mode; in this example, rstudiouser will be the single user:

/etc/rstudio/rserver.conf

# Run the server under the single user account
server-user=rstudiouser

# Disable authentication altogether, since only one user can authenticate
auth-none=1

# Disable project sharing, since adjusting file permissions requires privilege
server-project-sharing=0

# Disable PAM sessions, since privilege is required to open and close PAM sessions
auth-pam-sessions-enabled=0

Note

Single user mode and Launcher are incompatible, as the Launcher process requires the root user for Authentication. See the Launcher Configuration section of this guide for more information.

Finally, if you are using a service manager to invoke Workbench, you will need to configure your service manager to start Workbench under the desired account. For example, if you are using the systemd init system, run sudo systemctl edit rstudio-server and add the following directive:

[Service]
User=rstudiouser