Re: [MAINTAINERS SUMMIT] re-think of richACLs in AI/LLM era

[Jan Kara <jack@suse.cz>]

Hi Coly!

Maintainers summit is about process issues with the Linux kernel. Your
proposal is for a technical discussion so it doesn't really fit there. More
fitting would be a Kernel summit track at LPC which is for technical
topics. Given your topic is mostly a discussion on a relatively specialized
filesystem topic, I think the best venue for this would be LSFMM summit
next spring where you get the biggest concentration of people that have
something to say to this topic. (OTOH it's going to be in Europe so I
understand the location needn't be as convenient for you as LPC).

I'm not really on program committee for either a Maintainers summit or LPC
so take this just as a friendly advice from a bystander :)

								Honza

On Mon 08-09-25 16:33:54, Coly Li wrote:
> This is Coly Li. I’ve 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’s slow
> but that’s expected and acceptable. They can even come back to check the results
> weeks later.
> 
> In our use case, different people or roles store their personal and sensitive
> 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 for
> scalability and performance:
> - As the number and size of files increase, storing all access control rules in
>   user space memory doesn’t scale—especially on normal machines without huge
>   memory resources.
> - For some hot data sets (a group of files and directories), checking access
>   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’t enough. A high-level policy agent (in user space) is still needed for
> task/session-oriented access and sharing policy control, but RichACL can help
> implement file system-level access control. This would give us a context-aware
> and highly efficient access control implementation.
> 
> What I’d 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 one-
> million active installations running daily. This is a real workload for RichACL
> and represents real feature demand from end users. If you’re interested in this
> topic, we’d be happy to provide more details about the access control
> requirements in AI workloads and even show a live demo of the use case.
> 
> Thanks in advance.
> 
> Coly Li
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR