Propagate use_firewall

Author: yeldarby

CHANGELOG.md

@@ -6,6 +6,17 @@ This changelog documents user-facing updates (features, enhancements, fixes, and
 
 <!-- NEW CONTENT GENERATED BELOW. PLEASE PRESERVE THIS COMMENT. -->
 
+### 1.2.6 (2025-09-01)
+
+**Bug fixes:**
+- Fixed critical firewall flag propagation issue for non-hydrated (lazy-loaded) class methods when using `modal.Cls.from_name()` with `use_firewall=True`
+- The `use_firewall` flag is now properly propagated to methods accessed on class instances before the class is fully hydrated
+- This fix ensures that secure deserialization with `rffickle` is active on the very first execution after server startup, closing a security vulnerability where the first execution could bypass the firewall
+
+**Technical details:**
+- Modified `_Obj.__getattr__` method in `modal/cls.py` to copy the `_use_firewall` flag from the class service function to lazy-loaded method functions
+- This ensures the firewall protection is active even for non-hydrated class instances, which is the typical state for `Cls.from_name()` on first access
+
 ### 1.2.5 (2025-09-01)
 
 **Bug fixes:**

RELEASE_NOTES.md

@@ -1,28 +1,37 @@
-# Roboflow Modal Client Fork v1.2.5
+# Roboflow Modal Client Fork v1.2.6
 
 ## Summary
-This release fixes a critical bug in the firewall flag propagation for parameterized Modal classes, ensuring secure deserialization works correctly when using `modal.Cls.from_name()` with the `use_firewall=True` parameter.
+This release fixes a critical security vulnerability where the firewall flag was not properly propagated to lazy-loaded (non-hydrated) class methods, allowing pickle deserialization exploits to succeed on the first execution after server startup.
 
-## Bug Fix
+## Critical Security Fix
 
-### Firewall Flag Propagation for Parameterized Classes
-- **Issue**: When using `modal.Cls.from_name(..., use_firewall=True)` with parameterized classes, the firewall flag was not being propagated to instance methods
-- **Impact**: This prevented proper secure deserialization with `rffickle` when executing untrusted code in Modal sandboxes
-- **Fix**: Added firewall flag propagation in `_bind_instance_method` function in `modal/cls.py`
+### Firewall Flag Propagation for Non-Hydrated Class Methods
+- **Issue**: When using `modal.Cls.from_name(..., use_firewall=True)`, the firewall flag was not being propagated to methods accessed on non-hydrated class instances (typical state on first access)
+- **Security Impact**: This allowed pickle deserialization exploits to bypass the firewall on the FIRST execution after server startup
+- **Fix**: Modified `_Obj.__getattr__` in `modal/cls.py` to properly copy the `_use_firewall` flag to lazy-loaded method functions
 
 ## Technical Details
 
-The fix ensures that when you use the following pattern:
+The fix ensures that even when accessing methods on non-hydrated class instances (common with `Cls.from_name()`), the firewall protection is active:
+
 ```python
+# This now properly protects against exploits even on first execution:
 cls = modal.Cls.from_name("app-name", "ClassName", use_firewall=True)
-instance = cls(param1="value1", param2="value2")
-result = instance.some_method.remote(...)  # Now correctly uses firewall
+instance = cls(workspace_id="workspace")
+result = instance.execute_block.remote(...)  # Firewall active from first call
 ```
 
-The `use_firewall` flag is properly inherited by the method, ensuring secure deserialization throughout the execution chain.
+### Root Cause
+- When a class is loaded via `Cls.from_name()`, it starts in a non-hydrated state
+- Method access through `__getattr__` creates lazy-loaded functions
+- Previously, these lazy-loaded functions didn't inherit the `_use_firewall` flag
+- This meant the first execution (before hydration) was vulnerable
+
+### The Fix
+Modified the lazy loader creation in `_Obj.__getattr__` to copy the firewall flag from the class service function to the method function, ensuring protection is active even before hydration.
 
 ## Files Changed
-- `modal/cls.py` - Added `_use_firewall` flag propagation in `_bind_instance_method`
+- `modal/cls.py` - Modified `_Obj.__getattr__` to propagate `_use_firewall` flag to lazy-loaded methods
 
 ## How to Deploy to PyPI
 
@@ -37,15 +46,16 @@ python -m twine upload dist/*
 ```
 
 ## Testing
-Ensure that parameterized classes with firewall enabled properly block pickle-based attacks:
-- Test with `modal.Cls.from_name()` using `use_firewall=True`
-- Verify that instance methods inherit the firewall setting
-- Confirm that pickle deserialization attacks are blocked
+Critical tests to verify the fix:
+- Test with `modal.Cls.from_name()` using `use_firewall=True` 
+- Verify firewall blocks exploits on FIRST execution after server startup
+- Confirm no regression for hydrated class instances
+- Test with both parameterized and non-parameterized classes
 
 ## Version History
+- v1.2.6 - Fixed critical firewall bypass for non-hydrated class methods (first execution vulnerability)
 - v1.2.5 - Fixed firewall flag propagation for parameterized classes
 - v1.2.4 - Fixed import issues
 - v1.2.3 - Fixed grpclib/grpcio incompatibility
 - v1.2.2 - Added grpcio dependency
 - v1.2.1 - Fixed PyPI package build
-- v1.2.0 - Initial Roboflow fork with rffickle integration

modal/cls.py

@@ -434,12 +434,16 @@ async def method_loader(fun, resolver: Resolver, existing_object_id):
 
         # The reason we don't *always* use this lazy loader is because it precludes attribute access
         # on local classes.
-        return _Function._from_loader(
+        fun = _Function._from_loader(
             method_loader,
             rep=f"Method({self._cls._name}.{k})",
             deps=lambda: [],  # TODO: use cls as dep instead of loading inside method_loader?
             hydrate_lazily=True,
         )
+        # Copy the firewall flag from the class service function if it exists
+        if self._cls._class_service_function and hasattr(self._cls._class_service_function, '_use_firewall'):
+            fun._use_firewall = self._cls._class_service_function._use_firewall
+        return fun
 
 
 Obj = synchronize_api(_Obj)

modal_version/__init__.py

@@ -1,4 +1,4 @@
 # Copyright Modal Labs 2025
 """Supplies the current version of the modal client library."""
 
-__version__ = "1.2.5"
+__version__ = "1.2.6"