render_service.py: new FastAPI app with /render, /select, /render_diff
endpoints that wrap run_sandboxed — listens on a Unix domain socket.
service.py: imports the three pipeline functions from render_service.py;
delegates to render service via httpx when IFCURL_RENDER_SOCKET is set,
falls back to direct run_sandboxed when unset (single-service mode).
__main__.py: add 'render-service' subcommand (--socket PATH).
pyproject.toml: add httpx to service optional deps.
ifcurl-api.service: renamed from ifcurl-preview.service; sets
IFCURL_RENDER_SOCKET, adds AF_UNIX to RestrictAddressFamilies.
ifcurl-render.service: new hardened unit — AF_UNIX only, ~execve
~execveat blocked, no credentials, separate ifcurl-render user.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
execve is actually permitted — it arrives via @default which is included in
@system-service. The main service needs it for GitPython's git CLI calls.
Blocking execve only in render subprocesses would require per-process seccomp,
which is not worth the complexity for this threat model.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
ifcmerge defaults to preserving remote IDs; --prioritise-local preserves local
IDs instead. For Forgejo merge commits, %A is main (local) so ifcmerge_ours
(--prioritise-local) is the right driver — main's IDs are preserved and the
PR branch is renumbered. For developer rebases from main, %B is main (remote)
so the plain ifcmerge driver (no flag) preserves main's IDs by default.
Update /etc/gitattributes to use ifcmerge_ours for server-side merges, and
update README with a direction table clarifying which driver to use when.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Use CacheDirectory=ifcurl (systemd creates /var/cache/ifcurl owned by the
service user) and XDG_CACHE_HOME=/var/cache so platformdirs resolves to
that path. Remove the /root/.cache/ifcurl ReadWritePaths entry which was
inaccessible to the unprivileged ifcurl user.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Add sandboxing directives to limit blast radius from a compromised render
subprocess:
- NoNewPrivileges + RestrictSUIDSGID: no privilege escalation
- ProtectSystem=strict + ProtectHome: Forgejo data tree is unwritable
- PrivateTmp: isolated /tmp
- RestrictAddressFamilies=AF_INET AF_INET6: no Unix socket access to Forgejo
- SystemCallFilter=@system-service @process @files @io-event @network-io:
allows fork/clone (needed by ifcopenshell geom workers) but excludes
execve/execveat so an attacker cannot exec a shell
- RestrictNamespaces, LockPersonality, ProtectKernelTunables, etc.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Investigation confirmed: Forgejo's git merge-tree --write-tree (git ≥2.38)
does invoke configured merge drivers for .ifc files.
Key finding: bare repositories do NOT read committed .gitattributes — the
merge driver is silently skipped without a system-wide core.attributesFile.
Changes:
- server-config/gitattributes: new file to deploy at /etc/gitattributes,
containing "*.ifc merge=ifcmerge"
- server-config/gitconfig-ifcmerge: adds [core] attributesFile = /etc/gitattributes
and explains the bare-repo constraint
- forgejo/README.md: rewrites ifcmerge section with investigation findings,
deployment steps, and distinction between server-side vs client-side setup
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- forgejo/server-config/ifcurl-preview.service: systemd unit for the preview
service with dedicated user, EnvironmentFile for cache config, and
--allowed-hosts in ExecStart
- forgejo/server-config/gitconfig-ifcmerge: registers two [merge] driver
variants (ifcmerge and ifcmerge_ours) for the asymmetric .ifc merge case
- forgejo/README.md: systemd deployment section (manual + service), ifcmerge
section covering Perl script install, driver registration, per-repo
gitattributes, and merge-direction constraint (merge-commit preserves main's IDs)
- README.md: remove stale "IFC file proxy" description; update quick-summary
to show systemd install path
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
