 8d9b62daf3
			
		
	
	8d9b62daf3
	
	
	
		
			
			This commit implements Phase 2 of the CHORUS Task Execution Engine development plan, providing a comprehensive execution environment abstraction layer with Docker container sandboxing support. ## New Features ### Core Sandbox Interface - Comprehensive ExecutionSandbox interface with isolated task execution - Support for command execution, file I/O, environment management - Resource usage monitoring and sandbox lifecycle management - Standardized error handling with SandboxError types and categories ### Docker Container Sandbox Implementation - Full Docker API integration with secure container creation - Transparent repository mounting with configurable read/write access - Advanced security policies with capability dropping and privilege controls - Comprehensive resource limits (CPU, memory, disk, processes, file handles) - Support for tmpfs mounts, masked paths, and read-only bind mounts - Container lifecycle management with proper cleanup and health monitoring ### Security & Resource Management - Configurable security policies with SELinux, AppArmor, and Seccomp support - Fine-grained capability management with secure defaults - Network isolation options with configurable DNS and proxy settings - Resource monitoring with real-time CPU, memory, and network usage tracking - Comprehensive ulimits configuration for process and file handle limits ### Repository Integration - Seamless repository mounting from local paths to container workspaces - Git configuration support with user credentials and global settings - File inclusion/exclusion patterns for selective repository access - Configurable permissions and ownership for mounted repositories ### Testing Infrastructure - Comprehensive test suite with 60+ test cases covering all functionality - Docker integration tests with Alpine Linux containers (skipped in short mode) - Mock sandbox implementation for unit testing without Docker dependencies - Security policy validation tests with read-only filesystem enforcement - Resource usage monitoring and cleanup verification tests ## Technical Details ### Dependencies Added - github.com/docker/docker v28.4.0+incompatible - Docker API client - github.com/docker/go-connections v0.6.0 - Docker connection utilities - github.com/docker/go-units v0.5.0 - Docker units and formatting - Associated Docker API dependencies for complete container management ### Architecture - Interface-driven design enabling multiple sandbox implementations - Comprehensive configuration structures for all sandbox aspects - Resource usage tracking with detailed metrics collection - Error handling with retryable error classification - Proper cleanup and resource management throughout sandbox lifecycle ### Compatibility - Maintains backward compatibility with existing CHORUS architecture - Designed for future integration with Phase 3 Core Task Execution Engine - Extensible design supporting additional sandbox implementations (VM, process) This Phase 2 implementation provides the foundation for secure, isolated task execution that will be integrated with the AI model providers from Phase 1 in the upcoming Phase 3 development. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
		
			
				
	
	
		
			101 lines
		
	
	
		
			3.6 KiB
		
	
	
	
		
			Go
		
	
	
	
	
	
			
		
		
	
	
			101 lines
		
	
	
		
			3.6 KiB
		
	
	
	
		
			Go
		
	
	
	
	
	
| //go:build go1.21
 | |
| // +build go1.21
 | |
| 
 | |
| /*
 | |
| Copyright 2023 The logr Authors.
 | |
| 
 | |
| Licensed under the Apache License, Version 2.0 (the "License");
 | |
| you may not use this file except in compliance with the License.
 | |
| You may obtain a copy of the License at
 | |
| 
 | |
|     http://www.apache.org/licenses/LICENSE-2.0
 | |
| 
 | |
| Unless required by applicable law or agreed to in writing, software
 | |
| distributed under the License is distributed on an "AS IS" BASIS,
 | |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 | |
| See the License for the specific language governing permissions and
 | |
| limitations under the License.
 | |
| */
 | |
| 
 | |
| package logr
 | |
| 
 | |
| import (
 | |
| 	"context"
 | |
| 	"log/slog"
 | |
| )
 | |
| 
 | |
| // FromSlogHandler returns a Logger which writes to the slog.Handler.
 | |
| //
 | |
| // The logr verbosity level is mapped to slog levels such that V(0) becomes
 | |
| // slog.LevelInfo and V(4) becomes slog.LevelDebug.
 | |
| func FromSlogHandler(handler slog.Handler) Logger {
 | |
| 	if handler, ok := handler.(*slogHandler); ok {
 | |
| 		if handler.sink == nil {
 | |
| 			return Discard()
 | |
| 		}
 | |
| 		return New(handler.sink).V(int(handler.levelBias))
 | |
| 	}
 | |
| 	return New(&slogSink{handler: handler})
 | |
| }
 | |
| 
 | |
| // ToSlogHandler returns a slog.Handler which writes to the same sink as the Logger.
 | |
| //
 | |
| // The returned logger writes all records with level >= slog.LevelError as
 | |
| // error log entries with LogSink.Error, regardless of the verbosity level of
 | |
| // the Logger:
 | |
| //
 | |
| //	logger := <some Logger with 0 as verbosity level>
 | |
| //	slog.New(ToSlogHandler(logger.V(10))).Error(...) -> logSink.Error(...)
 | |
| //
 | |
| // The level of all other records gets reduced by the verbosity
 | |
| // level of the Logger and the result is negated. If it happens
 | |
| // to be negative, then it gets replaced by zero because a LogSink
 | |
| // is not expected to handled negative levels:
 | |
| //
 | |
| //	slog.New(ToSlogHandler(logger)).Debug(...) -> logger.GetSink().Info(level=4, ...)
 | |
| //	slog.New(ToSlogHandler(logger)).Warning(...) -> logger.GetSink().Info(level=0, ...)
 | |
| //	slog.New(ToSlogHandler(logger)).Info(...) -> logger.GetSink().Info(level=0, ...)
 | |
| //	slog.New(ToSlogHandler(logger.V(4))).Info(...) -> logger.GetSink().Info(level=4, ...)
 | |
| func ToSlogHandler(logger Logger) slog.Handler {
 | |
| 	if sink, ok := logger.GetSink().(*slogSink); ok && logger.GetV() == 0 {
 | |
| 		return sink.handler
 | |
| 	}
 | |
| 
 | |
| 	handler := &slogHandler{sink: logger.GetSink(), levelBias: slog.Level(logger.GetV())}
 | |
| 	if slogSink, ok := handler.sink.(SlogSink); ok {
 | |
| 		handler.slogSink = slogSink
 | |
| 	}
 | |
| 	return handler
 | |
| }
 | |
| 
 | |
| // SlogSink is an optional interface that a LogSink can implement to support
 | |
| // logging through the slog.Logger or slog.Handler APIs better. It then should
 | |
| // also support special slog values like slog.Group. When used as a
 | |
| // slog.Handler, the advantages are:
 | |
| //
 | |
| //   - stack unwinding gets avoided in favor of logging the pre-recorded PC,
 | |
| //     as intended by slog
 | |
| //   - proper grouping of key/value pairs via WithGroup
 | |
| //   - verbosity levels > slog.LevelInfo can be recorded
 | |
| //   - less overhead
 | |
| //
 | |
| // Both APIs (Logger and slog.Logger/Handler) then are supported equally
 | |
| // well. Developers can pick whatever API suits them better and/or mix
 | |
| // packages which use either API in the same binary with a common logging
 | |
| // implementation.
 | |
| //
 | |
| // This interface is necessary because the type implementing the LogSink
 | |
| // interface cannot also implement the slog.Handler interface due to the
 | |
| // different prototype of the common Enabled method.
 | |
| //
 | |
| // An implementation could support both interfaces in two different types, but then
 | |
| // additional interfaces would be needed to convert between those types in FromSlogHandler
 | |
| // and ToSlogHandler.
 | |
| type SlogSink interface {
 | |
| 	LogSink
 | |
| 
 | |
| 	Handle(ctx context.Context, record slog.Record) error
 | |
| 	WithAttrs(attrs []slog.Attr) SlogSink
 | |
| 	WithGroup(name string) SlogSink
 | |
| }
 |