From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sg-1-31.ptr.blmpb.com (sg-1-31.ptr.blmpb.com [118.26.132.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2FEBD21322F for ; Mon, 8 Sep 2025 08:36:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=118.26.132.31 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757320590; cv=none; b=sLAWNrZup5D4lyffprz6/xcox8rLGNN9ruEuwvUoSOWKkB8/Vx9Egm7Nvn8ATHukYm3bp5qQhrCCyPbFBoSWk3L0UXtGivMZOOyTjvJC1DA91MJmAUWmbDMJASHTD+3ho4Tfhcrb34A0nUu5nTPT4DhgXT5AHZeLmBBdzcuT5U0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757320590; c=relaxed/simple; bh=vj00WcnfKT4wfhLIdpjO78UWR9vSVVgwQ/mIDo5IbtU=; h=Message-Id:To:Date:Subject:Mime-Version:From:Content-Type; b=LnAWso+sZg2Ql0bv4sIRVMSnqlkrxBCJc75njLu7tKs25MgLEQakPOYicWgrF4PkdOw5d5zgmeEn5GAyHqOMQ1DKc/kRhBimVAn4ndPEFuD786PN0P3pw+NvG88OX1rKQFe5+DiKBtAJ6W72kpj99MT8VhHzpZU6AU/4JB6do7s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=fnnas.com; spf=fail smtp.mailfrom=fnnas.com; dkim=pass (2048-bit key) header.d=fnnas-com.20200927.dkim.feishu.cn header.i=@fnnas-com.20200927.dkim.feishu.cn header.b=Yjw2JEbu; arc=none smtp.client-ip=118.26.132.31 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=fnnas.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=fnnas.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=fnnas-com.20200927.dkim.feishu.cn header.i=@fnnas-com.20200927.dkim.feishu.cn header.b="Yjw2JEbu" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=s1; d=fnnas-com.20200927.dkim.feishu.cn; t=1757320447; h=from:subject:mime-version:from:date:message-id:subject:to:cc: reply-to:content-type:mime-version:in-reply-to:message-id; bh=PX2SWg92N3VcVsQtCfNESU5znh1V1o1UCF1WqzNMBXo=; b=Yjw2JEbuXEqsZOBK0v7dbRdIxJE5hLQ8+PqEkK1n6fYONvRf18zN6AuuOTTvx/kWvleOlk k325Qz1yusg+Eqd5eMzEn6VAOt0bLSOFmxowp1SU2U3cV74bNyIBQbX6ocgNZx/hkuySCb NAMgt5LiA7EMx6pKHMzs9u1/S5squ+ZmKNXKxX95y3jlz3w0gvU3aG7zsrfEfNqEe+hps1 NarS1Nfz5FWT8iAKvKu0FpgxA3Sz0RnLjuhfhinrosk1RtxoBW5Tx/Lkdoy7i74YTVKaaP Z9IAB5K+ZxWavTZ9F4BITogqU7ebm0DSEJfzlfvBCOo2I7gF/dW10bakpbmtqQ== Message-Id: To: Date: Mon, 8 Sep 2025 16:33:54 +0800 X-Mailer: Apple Mail (2.3826.700.81) X-Original-From: Coly Li Subject: [MAINTAINERS SUMMIT] re-think of richACLs in AI/LLM era Precedence: bulk X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from smtpclient.apple ([120.245.64.195]) by smtp.feishu.cn with ESMTPS; Mon, 08 Sep 2025 16:34:05 +0800 From: "Coly Li" X-Lms-Return-Path: Content-Type: text/plain; charset=UTF-8 Hi folks, This is Coly Li. I=E2=80=99ve been maintaining bcache for a while and have = met Linus, Greg, Ted, and other maintainers in person at many conferences. Yes, I am a sustained and reliable kernel developer. Recently, I joined a startup (https://fnnas.com) that provides AI/LLM capabilities for personal or micro-enterprise storage. We help users share = and communicate AI/LLM-processed information from their stored data more conveniently. Our users can run highly compact LLMs on their own normal and inexpensive hardware to process photos, videos, and documents using AI. Of course, it= =E2=80=99s slow but that=E2=80=99s expected and acceptable. They can even come back to chec= k the results weeks later. In our use case, different people or roles store their personal and sensiti= ve data in the same storage pool, with different access controls granted to AI= /LLM processing tasks. When they share specific information or data with others within the same machine or over the internet, the access control hierarchy = or rules become highly complicated and impossible to handle with POSIX ACLs. We tried bypassing access control to user space, which worked well except f= or scalability and performance: - As the number and size of files increase, storing all access control rule= s in user space memory doesn=E2=80=99t scale=E2=80=94especially on normal mach= ines without huge memory resources. - For some hot data sets (a group of files and directories), checking acces= s control rules in user space and hooking back to the kernel is highly inefficient. Therefore, the RichACL project comes back to mind. Of course, RichACL alone isn=E2=80=99t enough. A high-level policy agent (in user space) is still ne= eded for task/session-oriented access and sharing policy control, but RichACL can he= lp implement file system-level access control. This would give us a context-aw= are and highly efficient access control implementation. What I=E2=80=99d like to discuss is: - After almost 10 years, should we reconsider RichACL in the AI/LLM era? - What are the major barriers or remaining work needed to get RichACLs into upstream? Since our first public beta was released 13 months ago, we now have over on= e- million active installations running daily. This is a real workload for Ric= hACL and represents real feature demand from end users. If you=E2=80=99re intere= sted in this topic, we=E2=80=99d be happy to provide more details about the access contr= ol requirements in AI workloads and even show a live demo of the use case. Thanks in advance. Coly Li