Keep Environment
To keep environment variables during a privileged task, you adjust your host privilege settings. This lets a user pass local shell variables into a root command. Teams often enable this option so deployment scripts can read local keys and paths. Still, broad rules let users pass bad paths that hijack system programs. If a role allows all variables through, an attacker can gain full host control. How the keep environment workflow operates on Linux hosts When a user runs a command as root, the
Environment: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To keep environment variables during a privileged task, you adjust your host privilege settings. This lets a user pass local shell variables into a root command. Teams often enable this option so deployment scripts can read local keys and paths. Still, broad rules let users pass bad paths that hijack system programs. If a role allows all variables through, an attacker can gain full host control.
How the keep environment workflow operates on Linux hosts
When a user runs a command as root, the system wipes the shell state. It starts a clean shell with safe defaults for paths and language settings. This clean slate stops local user settings from changing how root programs run. Sometimes an app or script needs a specific local variable to work right. For example, a tool might need a custom path or an app key.
To fix this, admins set up a rule to keep environment values intact. The host privilege file holds an allowlist of safe variable names. When the user runs the task, the host checks each variable against this list. It copies only the matched variables into the new root session. Admins can also let a specific role keep all variables via a command flag. That wider option skips the allowlist and passes the whole user shell state through.
Why variable allowlists do not control commands in flight
Setting up a strict variable allowlist solves an important host safety problem. It stops users from passing unsafe library paths into a root shell. It also keeps local shell tricks from breaking system tools during a login. The host rule decides who can run a tool and which variables survive.
Yet this native setup leaves a big gap during daily work. Once the root command starts, the host stops checking what the user does. A developer with valid rights can still run a bad query or delete files. Also, variables often hold secret keys in plain text inside the user shell. Anyone who can read the local process list might see those keys. The host log records the start command, not the actions inside an interactive shell. If a script reads customer emails or card numbers, the host cannot rewrite them. Teams need a way to check each command and mask sensitive data in results.
Environment: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Best practices for safer shell variables and secrets
First, never allow a role to keep the whole shell state at once. Always write an explicit list of the exact variable names a script needs. Never add system path or library load variables to that safe list. Those specific values let a user point root tools at fake code files.
Second, avoid storing secret keys or passwords inside local shell variables. Local files and process checks can expose those values to other tools. Instead, keep secrets out of the user shell so people never handle raw keys. Finally, pair your host rules with controls that check every command and query live. Masking rules can also rewrite phone numbers and national IDs in query output.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Why does a privileged command drop my local variables by default?
The system drops them to stop users from injecting bad paths into root tools. A clean shell state ensures that root programs run only trusted system code.
Which variables are the most dangerous to pass into a root shell?
Variables that set binary search paths or dynamic library locations are the most risky. They let a regular user trick a root program into running untrusted code.
Is it safe to pass database keys through kept shell variables?
No, keeping database keys in user shell variables exposes them in plain text. Local scripts or other processes on the host can read those values from memory.