Safeguard
Supply Chain•

How do you stop users adding conda channels on a shared server?

An administrator condarc with the final flag, plus allowlist and denylist channel settings, lets a shared conda install restrict where packages come from.

Safeguard Security Team
3 min read

Install conda in a location the administrator controls, then put a system condarc in its root. Mark the channel settings with the final flag so user files cannot override them. Conda also has allowlist and denylist channel settings for the same purpose.

The problem

On a shared analytics server, each user normally has their own condarc. One person adds an extra channel to get a package, and that user now installs from a source nobody reviewed. A restricted setup limits where packages can come from.

How the documentation does it

The conda guide to administering a multi-user installation describes this pattern:

  1. Install conda and any allowed packages in a place under administrator control that users can read.
  2. Create a condarc in the root directory of that installation. It overrides user level configuration.
  3. Use the final flag, written as a comment after the setting, on the settings you want to lock. The documentation compares it to the important rule in CSS: nothing else can overwrite it.

Its example locks the channel list and the channel alias:

channels: #!final
  - admin
channel_alias: https://conda.anaconda.org/ #!final

Because the default channels were not listed and the setting was final, users in that example could not download from the default channels. They had to change their own file to use only channels the administrator allowed.

Allowlists and denylists

Two more settings help here, allowlist_channels and denylist_channels. The denylist one was added in conda 24.9.0 to complement the allowlist. The documentation says they let you allow or deny specific channels in conda operations, which suits enterprise or multi user setups. The denylist takes precedence over the allowlist, and channels are normalized by base URL.

allowlist_channels:
  - defaults
  - conda-forge
denylist_channels:
  - https://example.invalid/untrusted

What this does not do

  • It controls the sources conda uses, not what is inside the packages.
  • Users with shell access can still run pip, download files, or install their own conda elsewhere in their home directory.
  • A restriction in a file is only as strong as who can write that file, so check permissions on the installation root.

A rollout plan

  1. Inventory the channels in use today, using the show sources command from the previous post on condarc order.
  2. Decide the approved list and host a mirror if you need one.
  3. Write the system condarc and test it with a normal user account.
  4. Tell users how to request a new channel and who approves it.
  5. Review the file permissions and the list every quarter.

Safeguard's policies and gates apply at the pull request and pipeline stage, which is a second line of defence once packages enter your code. A free scan is available at gold.safeguard.sh/scan.

Quick check

What does the final flag do?

A setting marked final cannot be overwritten by any other condarc source.

Which wins if a channel is on both the allowlist and the denylist?

The denylist takes precedence.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.