Describe the bug
After upgrading from BentoML 1.4.27 to 1.4.36, bentoml containerize fails when the bento's bentofile.yaml specifies a dockerfile_template:
ValueError: Accessing file outside of current working directory is not allowed.
This is a regression introduced in PR #5548 (commit 4e0eb007), which added a secure=True default to resolve_user_filepath in bentoml/_internal/utils/filesystem.py.
Context: Two-Step Build Pattern
We use the standard two-step BentoML workflow in CI:
bentoml build — packages the bento archive (model + service + dependencies)
bentoml containerize — produces the final Docker image from the archive
This separation is common in production pipelines where you need to inject secrets or private registry credentials at containerize time (e.g., --build-arg for pip index URLs, artifactory tokens, etc.) that shouldn't be baked into the bento archive itself. The dockerfile_template feature enables this by letting users customize the Dockerfile with additional build steps — such as configuring private PyPI mirrors or installing system packages — that require secrets only available in the CI environment.
This two-step workflow is now broken in 1.4.36 for any bento that uses dockerfile_template.
Root Cause
During bentoml containerize, BentoML extracts the bento archive to a temp directory under /tmp/..., then calls resolve_user_filepath(user_templates, build_ctx) in generate.py:183 to locate the Dockerfile.template. Because secure=True checks that the resolved path is relative to os.getcwd(), and /tmp is not under CWD, the call raises a ValueError.
The secure check is appropriate for bentoml build (where user-supplied paths should be under the project directory), but during bentoml containerize the build context is a BentoML-controlled temp directory — not a user-supplied path — so the check is a false positive.
Workaround
We are currently patching generate.py at install time via a sed command in our CI pipeline:
sed -i 's/resolve_user_filepath(user_templates, build_ctx)/resolve_user_filepath(user_templates, build_ctx, secure=False)/' \
"$(python -c 'import bentoml; print(bentoml.__path__[0])')/_internal/container/generate.py"
To reproduce
mkdir /tmp/bentoml-repro && cd /tmp/bentoml-repro
python -m venv .venv && source .venv/bin/activate
pip install bentoml==1.4.36
# Create minimal service
cat > service.py << 'EOF'
import bentoml
@bentoml.service(name="my_service")
class MyService:
@bentoml.api
def predict(self) -> str:
return "hello"
EOF
# Create custom Dockerfile template (common pattern for injecting private registry auth)
cat > Dockerfile.template << 'EOF'
{% extends bento_base_template %}
{% block SETUP_BENTO_COMPONENTS %}
{{ super() }}
RUN echo "custom dockerfile template"
{% endblock %}
EOF
# Create bentofile
cat > bentofile.yaml << 'EOF'
service: "service:MyService"
include:
- "*.py"
docker:
dockerfile_template: Dockerfile.template
EOF
# Step 1: Build succeeds
bentoml build
# Step 2: Containerize fails
bentoml containerize my_service:latest
Error Output
Traceback (most recent call last):
File ".venv/lib/python3.11/site-packages/bentoml/_internal/container/generate.py", line 183, in generate_containerfile
dir_path = os.path.dirname(resolve_user_filepath(user_templates, build_ctx))
...
File ".venv/lib/python3.11/site-packages/bentoml/_internal/utils/filesystem.py", line 155, in resolve_user_filepath
raise ValueError("Accessing file outside of current working directory is not allowed.")
ValueError: Accessing file outside of current working directory is not allowed.
Expected behavior
bentoml containerize should successfully resolve the Dockerfile.template from the extracted bento in /tmp and proceed with the Docker build, as it did in 1.4.27. The two-step build → containerize workflow with dockerfile_template should continue to work.
Suggested Fix
In generate.py:183, pass secure=False when resolving the template path during containerize, since the build context is a BentoML-managed temp directory (not a user-supplied path):
# Before (broken)
dir_path = os.path.dirname(resolve_user_filepath(user_templates, build_ctx))
# After (fixed)
dir_path = os.path.dirname(resolve_user_filepath(user_templates, build_ctx, secure=False))
Environment
- BentoML version: 1.4.36
- Python version: 3.11
- OS: Ubuntu 22.04 (CI) / macOS (local)
- Install method:
pip install bentoml==1.4.36
Describe the bug
After upgrading from BentoML 1.4.27 to 1.4.36,
bentoml containerizefails when the bento'sbentofile.yamlspecifies adockerfile_template:This is a regression introduced in PR #5548 (commit
4e0eb007), which added asecure=Truedefault toresolve_user_filepathinbentoml/_internal/utils/filesystem.py.Context: Two-Step Build Pattern
We use the standard two-step BentoML workflow in CI:
bentoml build— packages the bento archive (model + service + dependencies)bentoml containerize— produces the final Docker image from the archiveThis separation is common in production pipelines where you need to inject secrets or private registry credentials at containerize time (e.g.,
--build-argfor pip index URLs, artifactory tokens, etc.) that shouldn't be baked into the bento archive itself. Thedockerfile_templatefeature enables this by letting users customize the Dockerfile with additional build steps — such as configuring private PyPI mirrors or installing system packages — that require secrets only available in the CI environment.This two-step workflow is now broken in 1.4.36 for any bento that uses
dockerfile_template.Root Cause
During
bentoml containerize, BentoML extracts the bento archive to a temp directory under/tmp/..., then callsresolve_user_filepath(user_templates, build_ctx)ingenerate.py:183to locate theDockerfile.template. Becausesecure=Truechecks that the resolved path is relative toos.getcwd(), and/tmpis not under CWD, the call raises aValueError.The
securecheck is appropriate forbentoml build(where user-supplied paths should be under the project directory), but duringbentoml containerizethe build context is a BentoML-controlled temp directory — not a user-supplied path — so the check is a false positive.Workaround
We are currently patching
generate.pyat install time via a sed command in our CI pipeline:To reproduce
Error Output
Expected behavior
bentoml containerizeshould successfully resolve theDockerfile.templatefrom the extracted bento in/tmpand proceed with the Docker build, as it did in 1.4.27. The two-stepbuild→containerizeworkflow withdockerfile_templateshould continue to work.Suggested Fix
In
generate.py:183, passsecure=Falsewhen resolving the template path during containerize, since the build context is a BentoML-managed temp directory (not a user-supplied path):Environment
pip install bentoml==1.4.36