Building a Serverless File Manager: How Dual Audits Caught a Path Namespace Bug Before It Shipped

sh0 lets you spin up a Deno serverless function server with one click. You get a container, a volume, a domain, and an HTTPS endpoint. What you did not get -- until today -- was a way to actually deploy your functions from the dashboard. The "How to Deploy" section showed example code, but there was no file manager. No way to create hello.ts, write your handler, save it, and see it live at https://functions-fn.your-server.sh0.app/hello.

This session added that file manager. It also added a Volumes tab. And in the process of building it, two independent AI auditors found 12 issues across two audit rounds -- including a critical bug that would have broken every user interaction with the file tree.

This is a story about building inside containers, the treacherous gap between two path namespaces, and why the build-audit-audit methodology catches bugs that careful implementation does not.

The Problem: A Feature With No Interface

sh0's Function Servers are Deno containers backed by a Docker volume mounted at /app/functions/. Inside that container, a bootstrap script (_server.ts) acts as an HTTP router: it maps URL paths to .ts files. Drop hello.ts into the volume, and it is instantly available at /hello.

The architecture was sound. The developer experience was not. To deploy a function, you had to SSH into the server, find the Docker volume, and manually write files into it. The dashboard showed your function server running, showed its domain, showed an example -- but gave you no way to act on any of it.

The fix was a file manager inside the dashboard, scoped to the function server's container, with full create/edit/delete capabilities.

The Design: Reuse Everything, Scope Everything

sh0 already had two file managers:

Both use the same pattern: a reusable FileTree component on the left (lazy-loaded, expandable directory tree), a content panel on the right (directory listing or file editor), and a set of CRUD operations (create, read, write, delete) backed by docker exec or direct filesystem calls.

The function server file manager follows the same pattern, with one critical difference: all operations are scoped to /app/functions/. A developer should be able to create hello.ts but not read /etc/passwd. They should edit their functions but not overwrite the bootstrap script.

Backend: 6 Endpoints, One Container

The backend adds 6 new Axum routes:

GET    /function-servers/:id/browse      List directory
GET    /function-servers/:id/file        Read file (1MB limit)
PUT    /function-servers/:id/file        Write file (2MB limit)
POST   /function-servers/:id/files/mkdir Create directory
POST   /function-servers/:id/files/new   Create empty file
DELETE /function-servers/:id/files       Delete file/directory

Every request goes through the same flow:

1. Load the FunctionServer record from SQLite
2. Check RBAC (viewer for reads, developer for writes)
3. Resolve the container name (error if server is stopped)
4. Validate and normalize the path via validate_fn_path()
5. Execute the operation via docker exec

The path validation is the most important part:

rustfn validate_fn_path(path: &str) -> Result<String> {
    if path.contains('\0') {
        return Err(ApiError::Validation(
            "Path must not contain null bytes".into()));
    }
    if path.contains("..") {
        return Err(ApiError::Validation(
            "Path must not contain '..'".into()));
    }

    let full_path = if path == FUNCTIONS_ROOT
        || path.starts_with(FUNCTIONS_ROOT_SLASH) {
        path.to_string()
    } else if path.starts_with('/') {
        format!("{FUNCTIONS_ROOT}{path}")
    } else {
        format!("{FUNCTIONS_ROOT}/{path}")
    };

    // Final containment check
    if full_path != FUNCTIONS_ROOT
        && !full_path.starts_with(FUNCTIONS_ROOT_SLASH) {
        return Err(ApiError::Validation(
            "Path must be within the functions directory".into()));
    }

    Ok(full_path)
}

Three layers of defense:

1. Reject traversal tokens: .. and \0 (null bytes that could terminate C strings early in shell commands)
2. Normalize the path: Prepend /app/functions if the path does not already start with it
3. Verify containment: After normalization, confirm the result is exactly /app/functions or starts with /app/functions/ (with trailing slash -- without it, /app/functionsevil would pass)

That third check was added during the first audit. The original code used starts_with("/app/functions") without the trailing slash. The auditor caught it.

Frontend: Two Path Spaces, One Component

The frontend reuses FileTree -- the same lazy-loading tree component used by AppFiles. FileTree starts with a root node at path / and builds child paths like /${name}. This is "tree-space."

The backend works in "container-space": /app/functions/hello.ts.

The frontend sends tree-space paths (/hello.ts) to the backend. The backend normalizes them to container-space (/app/functions/hello.ts). The frontend never needs to know about /app/functions -- that is an implementation detail of the container layout.

This sounds clean. It was not clean on the first attempt.

The Bug That Both Auditors Found

The original implementation mixed the two path namespaces. Here is what the first version of FunctionFiles.svelte looked like:

javascript// Breadcrumb logic -- uses /app/functions as root
let breadcrumbs = $derived(() => {
    const root = '/app/functions';
    if (!selectedPath || selectedPath === root)
        return [{ name: 'functions/', path: root }];
    // ...build crumbs with /app/functions prefix
});

// Delete fallback -- falls back to /app/functions
const parentPath = selectedPath.split('/').slice(0, -1).join('/')
    || '/app/functions';

// Navigate -- uses /app/functions
const basePath = selectedPath === '/app/functions'
    ? '/app/functions' : selectedPath;

The problem: selectedPath comes from the FileTree, which works in tree-space. The tree reports /hello.ts, not /app/functions/hello.ts. But the breadcrumbs expected /app/functions/hello.ts. The delete fallback expected /app/functions. The navigation expected /app/functions.

What Broke

Breadcrumbs: The tree reports selectedPath = '/'. The breadcrumb checks selectedPath === '/app/functions' -- false. Falls through to the else branch, tries selectedPath.replace('/app/functions', '') on the string / -- no match, returns / unchanged. The breadcrumb renders with wrong paths. Clicking a breadcrumb sets selectedPath to /app/functions/utils, which the tree cannot match -- no node is highlighted.

Refresh after create/delete: After creating a file, fileTree?.refreshPath(basePath) is called. If basePath is /app/functions (from the delete fallback), findNode() in FileTree searches for a node with path: '/app/functions' -- none exists (tree nodes use /). The tree does not refresh. The user sees stale content.

Navigation: Clicking a breadcrumb sets the path into /app/functions-space. Clicking a tree node sets it into /-space. The two spaces mix in selectedPath, producing inconsistent behavior depending on which element the user clicked last.

Both auditors flagged this independently. Auditor 1 called it Critical. Auditor 2 traced every code path and confirmed the analysis, then downgraded to Important after realizing the backend normalization prevented data corruption -- only the UI broke.

The Fix

The fix was conceptually simple: make everything work in tree-space. The frontend never mentions /app/functions. Breadcrumbs show functions/ as a display label for the / path. Delete and create operations use / as the fallback parent. Navigation uses / as the root. The backend handles the translation transparently.

javascript// After: everything in tree-space
let breadcrumbs = $derived.by(() => {
    if (!selectedPath || selectedPath === '/')
        return [{ name: 'functions/', path: '/' }];
    const parts = selectedPath.split('/').filter(Boolean);
    const crumbs = [{ name: 'functions/', path: '/' }];
    let acc = '';
    for (const part of parts) {
        acc += `/${part}`;
        crumbs.push({ name: part, path: acc });
    }
    return crumbs;
});

Notice $derived.by() instead of $derived(). That was the second finding -- both auditors caught it. In Svelte 5, $derived(() => { ... }) with a block body stores the function itself as the derived value. $derived.by(() => { ... }) executes the function and stores the result. The first version happened to work because the template called breadcrumbs() (invoking the stored function), but it defeated Svelte's reactivity caching. A subtle bug that would cause unnecessary re-computations on every render.

Security: Protecting the Bootstrap Script

The function server's _server.ts is the bootstrap Deno HTTP router. If a user overwrites it with garbage, their entire function server stops working. If they delete it, same result.

The original implementation only protected _server.ts from deletion:

rustconst PROTECTED_FILES: &[&str] = &["_server.ts"];

// In fn_delete_file:
let filename = path.rsplit('/').next().unwrap_or("");
if PROTECTED_FILES.contains(&filename) {
    return Err(ApiError::Validation("Cannot delete _server.ts".into()));
}

Auditor 1 caught the gap: deletion was blocked, but writes were not. A developer could PUT /function-servers/:id/file with path=/_server.ts and overwrite the bootstrap script. The protection was meaningless.

The fix added write protection and touch protection:

rustfn is_protected_file(path: &str) -> bool {
    let relative = path.strip_prefix(FUNCTIONS_ROOT_SLASH).unwrap_or("");
    PROTECTED_FILES.contains(&relative)
}

This function is now called in three places: fn_write_file, fn_new_file (touch), and fn_delete_file. On the frontend, the file metadata bar shows a "Read-only" label instead of an Edit button when viewing _server.ts.

A design choice worth noting: is_protected_file only protects _server.ts at the root level. A user-created _server.ts inside a subdirectory like /utils/_server.ts is fully editable and deletable. The protection targets the specific bootstrap script, not the filename pattern.

The Audit Scoreboard

Here is the complete tally across two rounds:

Round 1

Round 2 (on fixed code)

The critical path namespace bug was completely eliminated in Round 1. Round 2 found no regressions from the fixes and focused on hardening: null byte rejection, consistent protection checks, and i18n hygiene.

What the Auditors Would Not Have Found

Not every finding was actionable. Several Important findings from Round 2 were pre-existing patterns across the entire codebase:

• No Axum body size limit: No route in sh0 has one. Adding it to function server writes without adding it everywhere would be inconsistent.
• check_function_server_access blocks the async runtime: Same pattern in every handler across all services (databases, auth servers, realtime servers). A systemic fix, not a per-feature fix.
• rm -rf without file-type check: Same pattern in storage.rs (the app file handler). Consistent behavior.

These findings were documented and skipped. They are real issues, but fixing them requires a broader refactor that should not be coupled to a feature implementation.

This is an important principle: auditors should find everything, but the builder should only fix what is scoped to the current work. An audit that produces a list of 20 findings, 15 of which are pre-existing, is still valuable -- it documents technical debt. But fixing pre-existing issues inside a feature branch creates risk: the diff grows, the review surface expands, and unrelated regressions become possible.

The Implementation Pattern: Container File Management via Docker Exec

For developers building similar features, here is the pattern we use for file operations inside Docker containers:

Browse: ls -la with Format Fallback

rust// Try GNU ls, fall back to BusyBox, then plain
let output = docker.exec_in_container(&container,
    vec!["ls", "-la", "--time-style=long-iso", dir]).await;

if !output.stderr.is_empty() && output.stdout.is_empty() {
    // Fallback to --full-time (BusyBox)
    // Then plain -la (Alpine minimal)
}

The Deno Alpine image uses GNU coreutils, so the first format always works. But the fallback chain exists because sh0's app file browser uses the same parse_ls_line function for any container image, and not all images have GNU ls.

Read: head -c with Size Limit

rustdocker.exec_in_container(&container,
    vec!["head", "-c", "1048576", path]).await

head -c 1048576 reads at most 1 MB. This prevents a user from reading a multi-GB log file and blowing up the API response. The file content is returned as a string in the JSON response -- binary files show a detection message on the frontend.

Write: sh -c 'cat > file' with Stdin

rustdocker.exec_in_container_stdin(&container,
    vec!["sh", "-c",
         format!("cat > '{}'", path.replace('\'', "'\\''"))],
    content.as_bytes()).await

The original implementation used tee, which echoes content to stdout. For a 1 MB file, that means the Docker exec transfers 2 MB: once as stdin, once as stdout echo. cat > writes stdin to the file without echoing. This was caught by Auditor 2 in Round 1.

The single-quote escaping (replace('\'', "'\\''")) handles filenames containing single quotes. The path has already been validated (no .., no null bytes, scoped to /app/functions/), so the only character that could break the shell command is the quote itself.

Conclusion

A file manager for serverless functions sounds simple: list files, read them, write them, delete them. Six CRUD endpoints. A tree component on the left, a text editor on the right.

The complexity was not in the operations. It was in the space between two path representations, the gap between tree-space (/hello.ts) and container-space (/app/functions/hello.ts). A gap that passed all mental testing -- "the backend normalizes, so it works" -- but broke the moment a user clicked a breadcrumb instead of a tree node.

The dual audit methodology exists precisely for bugs like this. The builder sees features. The auditor sees edges. The second auditor sees the edges of the edges. Twelve findings across two rounds, including one that would have broken every file operation in the dashboard, caught before a single user encountered it.

The function server file manager ships with: - Full CRUD with tree-based navigation - Protected bootstrap script (read-only in UI, write-blocked on backend) - 2 MB write limit, null byte rejection, strict path containment - Volume info tab showing the Docker volume mapping - 5-language i18n support

From the user's perspective, they click "New File," type hello.ts, write a handler, save, and their function is live. From the engineering perspective, that click traverses two path namespaces, four security checks, a Docker exec call, and twelve audit findings that were fixed before the code left the development machine.

That is the difference between "it works" and "it works correctly."

This is Part 54 of the sh0 engineering series. Previous: Spawning a Host Terminal From the Browser via Native PTY. The full series documents how sh0 was built from zero to production by a CEO in Abidjan and an AI CTO, with no human engineering team.