Re-think of richACLs in AI/LLM era
summary
fnnas ships an AI‑native NAS with over one‑million active installations and runs compact LLM agents that read photos, write metadata and create hard links but must never delete originals. Current attempts with eBPF and LSM hooks prove too slow, complex or unscalable; user‑space ACLs exhaust memory and time on large recursive changes. Requirements are concrete: explicit deny, writable while nondelable, efficient recursive inheritance and path‑dependent access checks. RichACL covers most needs but needs upstream VFS changes and testing before it can be adopted.
AI-written summary · about
chapters (10)
- 0:00Introduction and motivation
- 1:28AI agents processing private photos
- 4:54Public shared photos and privacy agents
- 8:28Four new access control requirements
- 14:13Path-dependent access control challenge
- 21:10Why eBPF and LSM hooks aren't enough
- 27:42Industry feedback and workarounds
- 33:22Windows ACL comparison and path dependency
- 36:12Q&A on snapshots and metadata
- 41:08Industry desire for upstreaming
related talks
39mSmarter Apps with Ash and GenAI
11mAccelerating and Streamlining LLM AI Deployments
15mWhy Security Matters: The Risks of Agentic AI and How to Mitigate Them
47mA Step-by-Step Guide to Securing Large Language Models (LLMs)
11mAccelerating and Streamlining LLM AI Deployments
33mAI Your Data
26mHow Bad Actors AbUse LLMs The Mechanisms That Enable Misuse and What We Can Do About
50mAI: A Tool for Software Architecture?