Files
llmx/llmx-cli/Dockerfile

60 lines
1.5 KiB
Docker
Raw Permalink Normal View History

chore(deps): bump node from 22-slim to 24-slim in /codex-cli (#1505) Bumps node from 22-slim to 24-slim. [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=node&package-manager=docker&previous-version=22-slim&new-version=24-slim)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
2025-07-10 12:11:44 -07:00
FROM node:24-slim
ARG TZ
ENV TZ="$TZ"
# Install basic development tools, ca-certificates, and iptables/ipset, then clean up apt cache to reduce image size
RUN apt-get update && apt-get install -y --no-install-recommends \
aggregate \
ca-certificates \
curl \
dnsutils \
fzf \
gh \
git \
gnupg2 \
iproute2 \
ipset \
iptables \
jq \
less \
man-db \
procps \
unzip \
ripgrep \
zsh \
&& rm -rf /var/lib/apt/lists/*
# Ensure default node user has access to /usr/local/share
RUN mkdir -p /usr/local/share/npm-global && \
chown -R node:node /usr/local/share
ARG USERNAME=node
# Set up non-root user
USER node
# Install global packages
ENV NPM_CONFIG_PREFIX=/usr/local/share/npm-global
ENV PATH=$PATH:/usr/local/share/npm-global/bin
# Install codex
COPY dist/codex.tgz codex.tgz
RUN npm install -g codex.tgz \
&& npm cache clean --force \
&& rm -rf /usr/local/share/npm-global/lib/node_modules/codex-cli/node_modules/.cache \
&& rm -rf /usr/local/share/npm-global/lib/node_modules/codex-cli/tests \
&& rm -rf /usr/local/share/npm-global/lib/node_modules/codex-cli/docs
# Inside the container we consider the environment already sufficiently locked
# down, therefore instruct Codex CLI to allow running without sandboxing.
ENV CODEX_UNSAFE_ALLOW_NO_SANDBOX=1
fix: do not grant "node" user sudo access when using run_in_container.sh (#627) This exploration came out of my review of https://github.com/openai/codex/pull/414. `run_in_container.sh` runs Codex in a Docker container like so: https://github.com/openai/codex/blob/bd1c3deed9f4f103e755baa3f3a45e7a1c1a134b/codex-cli/scripts/run_in_container.sh#L51-L58 But then runs `init_firewall.sh` to set up the firewall to restrict network access. Previously, we did this by adding `/usr/local/bin/init_firewall.sh` to the container and adding a special rule in `/etc/sudoers.d` so the unprivileged user (`node`) could run the privileged `init_firewall.sh` script to open up the firewall for `api.openai.com`: https://github.com/openai/codex/blob/31d0d7a305305ad557035a2edcab60b6be5018d8/codex-cli/Dockerfile#L51-L56 Though I believe this is unnecessary, as we can use `docker exec --user root` from _outside_ the container to run `/usr/local/bin/init_firewall.sh` as `root` without adding a special case in `/etc/sudoers.d`. This appears to work as expected, as I tested it by doing the following: ``` ./codex-cli/scripts/build_container.sh ./codex-cli/scripts/run_in_container.sh 'what is the output of `curl https://www.openai.com`' ``` This was a bit funny because in some of my runs, Codex wasn't convinced it had network access, so I had to convince it to try the `curl` request: ![image](https://github.com/user-attachments/assets/80bd487c-74e2-4cd3-aa0f-26a6edd8d3f7) As you can see, when it ran `curl -s https\://www.openai.com`, it a connection failure, so the network policy appears to be working as intended. Note this PR also removes `sudo` from the `apt-get install` list in the `Dockerfile`.
2025-04-24 14:25:02 -07:00
# Copy and set up firewall script as root.
USER root
fix: do not grant "node" user sudo access when using run_in_container.sh (#627) This exploration came out of my review of https://github.com/openai/codex/pull/414. `run_in_container.sh` runs Codex in a Docker container like so: https://github.com/openai/codex/blob/bd1c3deed9f4f103e755baa3f3a45e7a1c1a134b/codex-cli/scripts/run_in_container.sh#L51-L58 But then runs `init_firewall.sh` to set up the firewall to restrict network access. Previously, we did this by adding `/usr/local/bin/init_firewall.sh` to the container and adding a special rule in `/etc/sudoers.d` so the unprivileged user (`node`) could run the privileged `init_firewall.sh` script to open up the firewall for `api.openai.com`: https://github.com/openai/codex/blob/31d0d7a305305ad557035a2edcab60b6be5018d8/codex-cli/Dockerfile#L51-L56 Though I believe this is unnecessary, as we can use `docker exec --user root` from _outside_ the container to run `/usr/local/bin/init_firewall.sh` as `root` without adding a special case in `/etc/sudoers.d`. This appears to work as expected, as I tested it by doing the following: ``` ./codex-cli/scripts/build_container.sh ./codex-cli/scripts/run_in_container.sh 'what is the output of `curl https://www.openai.com`' ``` This was a bit funny because in some of my runs, Codex wasn't convinced it had network access, so I had to convince it to try the `curl` request: ![image](https://github.com/user-attachments/assets/80bd487c-74e2-4cd3-aa0f-26a6edd8d3f7) As you can see, when it ran `curl -s https\://www.openai.com`, it a connection failure, so the network policy appears to be working as intended. Note this PR also removes `sudo` from the `apt-get install` list in the `Dockerfile`.
2025-04-24 14:25:02 -07:00
COPY scripts/init_firewall.sh /usr/local/bin/
RUN chmod 500 /usr/local/bin/init_firewall.sh
# Drop back to non-root.
USER node