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

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

[Coly Li]

Hi folks,

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

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

[Jan Kara]

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

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

[Coly Li]

Hi Jan,

> 2025年9月8日 18:52，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

Copied. I will resend the proposal by kernel summit track format.

> 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).
> 

Yes this time it is better for both time and location.


> 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 :)
> 

Thanks for your kind suggestion :-)

Coly Li


> 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

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

[Steven Rostedt]

On Mon, 8 Sep 2025 12:52:48 +0200
Jan Kara <jack@suse.cz> wrote:

> 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 :)
> 

As Jan has stated, this is a technical topic. But you can send it to this
list too. From Ted's original email:

    Related to the Maintainer's Summit, the Kernel Summit is organized as
    a track which is run in parallel with the other tracks at the Linux
    Plumbers Conference (LPC), and is open to all registered attendees of
    LPC.  The goal of the Kernel Summit track will be to provide a forum
    to discuss specific technical issues that would be easier to resolve
    in person than over e-mail.  The program committee will also consider
    "information sharing" topics if they are clearly of interest to the
    wider development community (i.e., advanced training in topics that
    would be useful to kernel developers).

    To suggest a topic for the Kernel Summit, please do two things. by
    September 10th, 2025. First, please send e-mail with a subject prefix of
    [TECH TOPIC] to ksummit@lists.linux.dev.  As before, please use a separate
    e-mail for each topic.

    Secondly, please create a topic at the Linux Plumbers Conference
    proposal submission site and target it to the Kernel Summit track:

        https://lpc.events/event/19/abstracts

    Please do both steps.  I'll try to notice if someone forgets one or
    the other, but your chances of making sure your proposal gets the
    necessary attention and consideration are maximized by submitting both
    to the mailing list and the web site.


The CfP is closing this Wednesday, so please submit it soon.

-- Steve

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

[Coly Li]

> 2025年9月8日 23:39，Steven Rostedt <rostedt@goodmis.org> 写道：
> 
> On Mon, 8 Sep 2025 12:52:48 +0200
> Jan Kara <jack@suse.cz> wrote:
> 
>> 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 :)
>> 
> 
> As Jan has stated, this is a technical topic. But you can send it to this
> list too. From Ted's original email:
> 
>    Related to the Maintainer's Summit, the Kernel Summit is organized as
>    a track which is run in parallel with the other tracks at the Linux
>    Plumbers Conference (LPC), and is open to all registered attendees of
>    LPC.  The goal of the Kernel Summit track will be to provide a forum
>    to discuss specific technical issues that would be easier to resolve
>    in person than over e-mail.  The program committee will also consider
>    "information sharing" topics if they are clearly of interest to the
>    wider development community (i.e., advanced training in topics that
>    would be useful to kernel developers).
> 
>    To suggest a topic for the Kernel Summit, please do two things. by
>    September 10th, 2025. First, please send e-mail with a subject prefix of
>    [TECH TOPIC] to ksummit@lists.linux.dev.  As before, please use a separate
>    e-mail for each topic.
> 
>    Secondly, please create a topic at the Linux Plumbers Conference
>    proposal submission site and target it to the Kernel Summit track:
> 
>        https://lpc.events/event/19/abstracts
> 
>    Please do both steps.  I'll try to notice if someone forgets one or
>    the other, but your chances of making sure your proposal gets the
>    necessary attention and consideration are maximized by submitting both
>    to the mailing list and the web site.
> 
> 
> The CfP is closing this Wednesday, so please submit it soon.

Yes, I already submitted the CfP on https://lpc.events/event/19/abstracts and got the confirmation email.

Also I resend another proposal email subjected with  [TECH TOPIC]  and almost identical message body.

Thanks for the hint!

Coly Li

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

[Randy Dunlap]

Hi,

On 9/8/25 8:42 AM, Coly Li wrote:
>> 2025年9月8日 23:39，Steven Rostedt <rostedt@goodmis.org> 写道：
>>

>>>
>>> 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 :)
>>>
>>
>> As Jan has stated, this is a technical topic. But you can send it to this
>> list too. From Ted's original email:
>>
>>    Related to the Maintainer's Summit, the Kernel Summit is organized as
>>    a track which is run in parallel with the other tracks at the Linux
>>    Plumbers Conference (LPC), and is open to all registered attendees of
>>    LPC.  The goal of the Kernel Summit track will be to provide a forum
>>    to discuss specific technical issues that would be easier to resolve
>>    in person than over e-mail.  The program committee will also consider
>>    "information sharing" topics if they are clearly of interest to the
>>    wider development community (i.e., advanced training in topics that
>>    would be useful to kernel developers).
>>
>>    To suggest a topic for the Kernel Summit, please do two things. by
>>    September 10th, 2025. First, please send e-mail with a subject prefix of
>>    [TECH TOPIC] to ksummit@lists.linux.dev.  As before, please use a separate
>>    e-mail for each topic.
>>
>>    Secondly, please create a topic at the Linux Plumbers Conference
>>    proposal submission site and target it to the Kernel Summit track:
>>
>>        https://lpc.events/event/19/abstracts
>>
>>    Please do both steps.  I'll try to notice if someone forgets one or
>>    the other, but your chances of making sure your proposal gets the
>>    necessary attention and consideration are maximized by submitting both
>>    to the mailing list and the web site.
>>
>>
>> The CfP is closing this Wednesday, so please submit it soon.
> 
> Yes, I already submitted the CfP on https://lpc.events/event/19/abstracts and got the confirmation email.
> 
> Also I resend another proposal email subjected with  [TECH TOPIC]  and almost identical message body.
> 
> Thanks for the hint!

Hi,
I don't object to such a topic, but I thought that LSMs were the wave
of the future for extended attributes or special capability handling.  ?

-- 
~Randy

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

[Paul Moore]

On Mon, Sep 8, 2025 at 7:23 PM Randy Dunlap <rdunlap@infradead.org> wrote:
> On 9/8/25 8:42 AM, Coly Li wrote:
> >> 2025年9月8日 23:39，Steven Rostedt <rostedt@goodmis.org> 写道：
> >>
> >>>
> >>> 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 :)
> >>>
> >>
> >> As Jan has stated, this is a technical topic. But you can send it to this
> >> list too. From Ted's original email:
> >>
> >>    Related to the Maintainer's Summit, the Kernel Summit is organized as
> >>    a track which is run in parallel with the other tracks at the Linux
> >>    Plumbers Conference (LPC), and is open to all registered attendees of
> >>    LPC.  The goal of the Kernel Summit track will be to provide a forum
> >>    to discuss specific technical issues that would be easier to resolve
> >>    in person than over e-mail.  The program committee will also consider
> >>    "information sharing" topics if they are clearly of interest to the
> >>    wider development community (i.e., advanced training in topics that
> >>    would be useful to kernel developers).
> >>
> >>    To suggest a topic for the Kernel Summit, please do two things. by
> >>    September 10th, 2025. First, please send e-mail with a subject prefix of
> >>    [TECH TOPIC] to ksummit@lists.linux.dev.  As before, please use a separate
> >>    e-mail for each topic.
> >>
> >>    Secondly, please create a topic at the Linux Plumbers Conference
> >>    proposal submission site and target it to the Kernel Summit track:
> >>
> >>        https://lpc.events/event/19/abstracts
> >>
> >>    Please do both steps.  I'll try to notice if someone forgets one or
> >>    the other, but your chances of making sure your proposal gets the
> >>    necessary attention and consideration are maximized by submitting both
> >>    to the mailing list and the web site.
> >>
> >>
> >> The CfP is closing this Wednesday, so please submit it soon.
> >
> > Yes, I already submitted the CfP on https://lpc.events/event/19/abstracts and got the confirmation email.
> >
> > Also I resend another proposal email subjected with  [TECH TOPIC]  and almost identical message body.
> >
> > Thanks for the hint!
>
> Hi,
> I don't object to such a topic, but I thought that LSMs were the wave
> of the future for extended attributes or special capability handling.  ?

I can't say I'm familiar with the RichACL concept, but generally
speaking yes, the LSM framework exists as a way to implement access
control mechanisms beyond the traditional Linux access controls (other
things too, but those aren't really relevant here).

-- 
paul-moore.com

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

[Coly Li]

On Mon, Sep 08, 2025 at 09:03:24PM +0800, Paul Moore wrote:
> On Mon, Sep 8, 2025 at 7:23 PM Randy Dunlap <rdunlap@infradead.org> wrote:
> > On 9/8/25 8:42 AM, Coly Li wrote:
> > >> 2025年9月8日 23:39，Steven Rostedt <rostedt@goodmis.org> 写道：
> > >>
> > >>>
> > >>> 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 :)
> > >>>
> > >>
> > >> As Jan has stated, this is a technical topic. But you can send it to this
> > >> list too. From Ted's original email:
> > >>
> > >>    Related to the Maintainer's Summit, the Kernel Summit is organized as
> > >>    a track which is run in parallel with the other tracks at the Linux
> > >>    Plumbers Conference (LPC), and is open to all registered attendees of
> > >>    LPC.  The goal of the Kernel Summit track will be to provide a forum
> > >>    to discuss specific technical issues that would be easier to resolve
> > >>    in person than over e-mail.  The program committee will also consider
> > >>    "information sharing" topics if they are clearly of interest to the
> > >>    wider development community (i.e., advanced training in topics that
> > >>    would be useful to kernel developers).
> > >>
> > >>    To suggest a topic for the Kernel Summit, please do two things. by
> > >>    September 10th, 2025. First, please send e-mail with a subject prefix of
> > >>    [TECH TOPIC] to ksummit@lists.linux.dev.  As before, please use a separate
> > >>    e-mail for each topic.
> > >>
> > >>    Secondly, please create a topic at the Linux Plumbers Conference
> > >>    proposal submission site and target it to the Kernel Summit track:
> > >>
> > >>        https://lpc.events/event/19/abstracts
> > >>
> > >>    Please do both steps.  I'll try to notice if someone forgets one or
> > >>    the other, but your chances of making sure your proposal gets the
> > >>    necessary attention and consideration are maximized by submitting both
> > >>    to the mailing list and the web site.
> > >>
> > >>
> > >> The CfP is closing this Wednesday, so please submit it soon.
> > >
> > > Yes, I already submitted the CfP on https://lpc.events/event/19/abstracts and got the confirmation email.
> > >
> > > Also I resend another proposal email subjected with  [TECH TOPIC]  and almost identical message body.
> > >
> > > Thanks for the hint!
> >

Hi Paul and Randy,

Thank you for suggesting LSM as another choice. 

> > Hi,
> > I don't object to such a topic, but I thought that LSMs were the wave
> > of the future for extended attributes or special capability handling.  ?
> 
> I can't say I'm familiar with the RichACL concept, but generally
> speaking yes, the LSM framework exists as a way to implement access
> control mechanisms beyond the traditional Linux access controls (other
> things too, but those aren't really relevant here).

Is it convenient for normal users or non-root processes (including the policy agent) to
setup the LSM rules? We need to allow normal users to set their own access control policy
for the data they owned.

Also there is a special case, e.g. a file’s parent directory doesn’t allow write
permission, but the file needs to grant delete permission.
4614 int do_unlinkat(int dfd, struct filename *name)
4615 {
[snipped]
4645                 inode = dentry->d_inode;
4646                 ihold(inode);
4647                 error = security_path_unlink(&path, dentry);
4648                 if (error)
4649                         goto exit3;
4650                 error = vfs_unlink(mnt_idmap(path.mnt), path.dentry->d_inode,
4651                                    dentry, &delegated_inode);
[snipped]
4563 int vfs_unlink(struct mnt_idmap *idmap, struct inode *dir,
4564                struct dentry *dentry, struct inode **delegated_inode)
4565 {
4566         struct inode *target = dentry->d_inode;
4567         int error = may_delete(idmap, dir, dentry, 0);
4568
4569         if (error)
4570                 return error;
[snipped]

It seems in do_unlinkat() the security check security_path_unlink() is called before
calling may_delete() inside vfs_unlink(). So even security rule permits to delete
this file but the parent directory doesn't grant write permission, such access control
still cannot be archieved.

We are open to any possible method to serve the complicated access controls in current
AI/LLM driven workloads. And the executive team decide to invest a few engineers and time
to work with other community deveopers on the promissing technial choice, and help to make
the effort to go into upstream kernel. Therefore we do want to hear all your voices and
advices, to make sure the effort will be on the correct tack.

Thanks again for your replies.

Coly Li

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

[Paul Moore]

On Wed, Sep 10, 2025 at 9:32 AM Coly Li <colyli@fnnas.com> wrote:
> On Mon, Sep 08, 2025 at 09:03:24PM +0800, Paul Moore wrote:

...

> > I can't say I'm familiar with the RichACL concept, but generally
> > speaking yes, the LSM framework exists as a way to implement access
> > control mechanisms beyond the traditional Linux access controls (other
> > things too, but those aren't really relevant here).
>
> Is it convenient for normal users or non-root processes (including the policy agent) to
> setup the LSM rules? We need to allow normal users to set their own access control policy
> for the data they owned.

Management of an individual LSM's configuration is generally left to
the individual LSM.  Some LSMs restrict their configuration knobs
behind capabilities or their own access controls, while others allow
unprivileged access to the configuration; it depends on the LSM's
security model.  As an unprivileged example, Landlock allows
applications, run by arbitrary users, to set their own Landlock
security policy via the Landlock API.

> Also there is a special case, e.g. a file’s parent directory doesn’t allow write
> permission, but the file needs to grant delete permission.
> 4614 int do_unlinkat(int dfd, struct filename *name)
> 4615 {
> [snipped]
> 4645                 inode = dentry->d_inode;
> 4646                 ihold(inode);
> 4647                 error = security_path_unlink(&path, dentry);
> 4648                 if (error)
> 4649                         goto exit3;
> 4650                 error = vfs_unlink(mnt_idmap(path.mnt), path.dentry->d_inode,
> 4651                                    dentry, &delegated_inode);
> [snipped]
> 4563 int vfs_unlink(struct mnt_idmap *idmap, struct inode *dir,
> 4564                struct dentry *dentry, struct inode **delegated_inode)
> 4565 {
> 4566         struct inode *target = dentry->d_inode;
> 4567         int error = may_delete(idmap, dir, dentry, 0);
> 4568
> 4569         if (error)
> 4570                 return error;
> [snipped]
>
> It seems in do_unlinkat() the security check security_path_unlink() is called before
> calling may_delete() inside vfs_unlink(). So even security rule permits to delete
> this file but the parent directory doesn't grant write permission, such access control
> still cannot be archieved.

One of the important parts of the LSM framework as a whole is that
LSMs can not grant access that would otherwise be blocked by the
standard/discretionary access controls built into the Linux kernel; in
other words, LSMs can only say "no" to an access, they can not grant
access by themselves.  Yes, this is by design, and no, I see no reason
to change that design decision at this point in time (doing so would
require a tremendous amount of work and likely introduce a fair number
of security regressions for quite some time).

-- 
paul-moore.com

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

[Coly Li]

On Wed, Sep 10, 2025 at 03:11:55PM +0800, Paul Moore wrote:
> On Wed, Sep 10, 2025 at 9:32 AM Coly Li <colyli@fnnas.com> wrote:
> > On Mon, Sep 08, 2025 at 09:03:24PM +0800, Paul Moore wrote:
> 
> ...
> 
> > > I can't say I'm familiar with the RichACL concept, but generally
> > > speaking yes, the LSM framework exists as a way to implement access
> > > control mechanisms beyond the traditional Linux access controls (other
> > > things too, but those aren't really relevant here).
> >
> > Is it convenient for normal users or non-root processes (including the policy agent) to
> > setup the LSM rules? We need to allow normal users to set their own access control policy
> > for the data they owned.
> 
> Management of an individual LSM's configuration is generally left to
> the individual LSM.  Some LSMs restrict their configuration knobs
> behind capabilities or their own access controls, while others allow
> unprivileged access to the configuration; it depends on the LSM's
> security model.  As an unprivileged example, Landlock allows
> applications, run by arbitrary users, to set their own Landlock
> security policy via the Landlock API.
> 

I forward the suggestion to our application team, and they try to evaluate
and replied the result.

Currently they are using bpf to do the access control rules checking, and
LSM access control method e.g. Landlock is quite similar to a rules based
control method. They still need to persist all the rules on disk, and load
the rules during system initlization time. When the number of rules increased,
the maintennance is complicated and slow.

Also the application team give me a use case, ask how to achieve the access
control effiently. Let me describe by the followed text.

Users store they photos on the system, and the compact AI module processes all
their photos and groups all the photos into different categories like pizza,
dogs, cats, foods or group photos. After the process done, users may see they
photos in different categories that the AI module thinks they should be in. Then
users may share the categories with photos to others. If indentical categories
shared by different users, the shared photos can be combined all together. And
AI module may continue to process the shared photos and generate new categaries
from the shared photos, e.g. pizza in the same city, cats and dogs in closed
location, group photos contains the most common people, etc. Now the differet
categories are implemented by different directories in the publicly shared
directory.

In each category directory, photos with a category (or attribution) can be
accessed as hard links to the original photo inodes and share the identical
inodes. All these category directories are created by the AI module, although
the photos are shared from each users. If a user is identified from a group
photo, and this user is noticed that the photo is publicly shared. If this user
doesn't want his face to be shared in public, for an optinal privacy protection
right, this user can remove the hardlink of the photo which his or her face is
in, that is he or she can remove the hardlink (dentry) under a publicly shared
directory which this user doesn't have write permission. Because this user can
be idnetified as owner of his or her face, and the photo has his face in, he or
she should have write permission to delete the photo, but no write permission to
other photos in same category directioy which his or her face is not in.

The above example is one of the simple case just for photos processing and
sharing in the AI context. The rules of access control are created or destoried
dynamically and maybe only exist for a short period. And the number of rules are
quite large.

Current rules based access control is inefficient and complicated to implement
for the above simple case, and the application team replies they don't see the
rules based LSM method can make it be more simple.

> > Also there is a special case, e.g. a file’s parent directory doesn’t allow write
> > permission, but the file needs to grant delete permission.
> > 4614 int do_unlinkat(int dfd, struct filename *name)
> > 4615 {
> > [snipped]
> > 4645                 inode = dentry->d_inode;
> > 4646                 ihold(inode);
> > 4647                 error = security_path_unlink(&path, dentry);
> > 4648                 if (error)
> > 4649                         goto exit3;
> > 4650                 error = vfs_unlink(mnt_idmap(path.mnt), path.dentry->d_inode,
> > 4651                                    dentry, &delegated_inode);
> > [snipped]
> > 4563 int vfs_unlink(struct mnt_idmap *idmap, struct inode *dir,
> > 4564                struct dentry *dentry, struct inode **delegated_inode)
> > 4565 {
> > 4566         struct inode *target = dentry->d_inode;
> > 4567         int error = may_delete(idmap, dir, dentry, 0);
> > 4568
> > 4569         if (error)
> > 4570                 return error;
> > [snipped]
> >
> > It seems in do_unlinkat() the security check security_path_unlink() is called before
> > calling may_delete() inside vfs_unlink(). So even security rule permits to delete
> > this file but the parent directory doesn't grant write permission, such access control
> > still cannot be archieved.
> 
> One of the important parts of the LSM framework as a whole is that
> LSMs can not grant access that would otherwise be blocked by the
> standard/discretionary access controls built into the Linux kernel; in
> other words, LSMs can only say "no" to an access, they can not grant
> access by themselves.  Yes, this is by design, and no, I see no reason
> to change that design decision at this point in time (doing so would
> require a tremendous amount of work and likely introduce a fair number
> of security regressions for quite some time).

I understand and agree the concern of security. But the reality is more and more
similar or relative access control requirements will sprint up from the AI/LLM
applications and use cases. We just want to solve the access control challenge,
and the LSM rules based methods are not easy for application developers.

Forgive me for the late response, because I wait for the feed back from our
application development teams.

Thanks.

Coly Li

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

[Randy Dunlap]

Hi Coly,

On 9/16/25 10:12 AM, Coly Li wrote:
> On Wed, Sep 10, 2025 at 03:11:55PM +0800, Paul Moore wrote:
>> On Wed, Sep 10, 2025 at 9:32 AM Coly Li <colyli@fnnas.com> wrote:
>>> On Mon, Sep 08, 2025 at 09:03:24PM +0800, Paul Moore wrote:
>>
>> ...
>>
>>>> I can't say I'm familiar with the RichACL concept, but generally
>>>> speaking yes, the LSM framework exists as a way to implement access
>>>> control mechanisms beyond the traditional Linux access controls (other
>>>> things too, but those aren't really relevant here).
>>>
>>> Is it convenient for normal users or non-root processes (including the policy agent) to
>>> setup the LSM rules? We need to allow normal users to set their own access control policy
>>> for the data they owned.
>>
>> Management of an individual LSM's configuration is generally left to
>> the individual LSM.  Some LSMs restrict their configuration knobs
>> behind capabilities or their own access controls, while others allow
>> unprivileged access to the configuration; it depends on the LSM's
>> security model.  As an unprivileged example, Landlock allows
>> applications, run by arbitrary users, to set their own Landlock
>> security policy via the Landlock API.
>>
> 
> I forward the suggestion to our application team, and they try to evaluate
> and replied the result.
> 
> Currently they are using bpf to do the access control rules checking, and
> LSM access control method e.g. Landlock is quite similar to a rules based
> control method. They still need to persist all the rules on disk, and load
> the rules during system initlization time. When the number of rules increased,
> the maintennance is complicated and slow.
> 
> Also the application team give me a use case, ask how to achieve the access
> control effiently. Let me describe by the followed text.
> 
> Users store they photos on the system, and the compact AI module processes all
> their photos and groups all the photos into different categories like pizza,
> dogs, cats, foods or group photos. After the process done, users may see they
> photos in different categories that the AI module thinks they should be in. Then
> users may share the categories with photos to others. If indentical categories
> shared by different users, the shared photos can be combined all together. And
> AI module may continue to process the shared photos and generate new categaries
> from the shared photos, e.g. pizza in the same city, cats and dogs in closed
> location, group photos contains the most common people, etc. Now the differet
> categories are implemented by different directories in the publicly shared
> directory.
> 
> In each category directory, photos with a category (or attribution) can be
> accessed as hard links to the original photo inodes and share the identical
> inodes. All these category directories are created by the AI module, although
> the photos are shared from each users. If a user is identified from a group
> photo, and this user is noticed that the photo is publicly shared. If this user
> doesn't want his face to be shared in public, for an optinal privacy protection
> right, this user can remove the hardlink of the photo which his or her face is
> in, that is he or she can remove the hardlink (dentry) under a publicly shared
> directory which this user doesn't have write permission. Because this user can
> be idnetified as owner of his or her face, and the photo has his face in, he or
> she should have write permission to delete the photo, but no write permission to
> other photos in same category directioy which his or her face is not in.


What permissions/rights does the AI module have such that it can create
a file in shared/photos/faces from my personal files?
The shared file with my photo is still owned by the sharing user, correct?
What are the permissions/owner of the parent directory?

What permissions are required in my personal photos directory to allow
files there to be shared?

It sounds to me like the AI was aggressive in sharing; now you (the user)
want to correct/fix that. The AI could be trained better, but that's too
difficult. (just playing devil's advocate there)

I haven't looked at this in any detail, but I'm wondering if an
intermediate directory level with "my" permissions/ownership would
allow a fix for this issue. Then I (the user) could remove the file
(the hardlink) from the intermediate directory. However, that might
leave some dangling link in the final shared directory. I don't know
enough about it to answer that.


> The above example is one of the simple case just for photos processing and
> sharing in the AI context. The rules of access control are created or destoried
> dynamically and maybe only exist for a short period. And the number of rules are
> quite large.
> 
> Current rules based access control is inefficient and complicated to implement
> for the above simple case, and the application team replies they don't see the
> rules based LSM method can make it be more simple.

[snip]

>> One of the important parts of the LSM framework as a whole is that
>> LSMs can not grant access that would otherwise be blocked by the
>> standard/discretionary access controls built into the Linux kernel; in
>> other words, LSMs can only say "no" to an access, they can not grant
>> access by themselves.  Yes, this is by design, and no, I see no reason
>> to change that design decision at this point in time (doing so would
>> require a tremendous amount of work and likely introduce a fair number
>> of security regressions for quite some time).
> 
> I understand and agree the concern of security. But the reality is more and more
> similar or relative access control requirements will sprint up from the AI/LLM
> applications and use cases. We just want to solve the access control challenge,
> and the LSM rules based methods are not easy for application developers.

Do you have control over the AI that does this photo directory magic?

Anyway, it sounds like a reasonable topic for the kernel summit (as a
Tech Topic) instead of the maintainer's summit (process stuff).

-- 
~Randy

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

[Jan Kara]

On Wed 17-09-25 01:12:48, Coly Li wrote:
> Users store they photos on the system, and the compact AI module processes all
> their photos and groups all the photos into different categories like pizza,
> dogs, cats, foods or group photos. After the process done, users may see they
> photos in different categories that the AI module thinks they should be in. Then
> users may share the categories with photos to others. If indentical categories
> shared by different users, the shared photos can be combined all together. And
> AI module may continue to process the shared photos and generate new categaries
> from the shared photos, e.g. pizza in the same city, cats and dogs in closed
> location, group photos contains the most common people, etc. Now the differet
> categories are implemented by different directories in the publicly shared
> directory.
> 
> In each category directory, photos with a category (or attribution) can be
> accessed as hard links to the original photo inodes and share the identical
> inodes. All these category directories are created by the AI module, although
> the photos are shared from each users. If a user is identified from a group
> photo, and this user is noticed that the photo is publicly shared. If this user
> doesn't want his face to be shared in public, for an optinal privacy protection
> right, this user can remove the hardlink of the photo which his or her face is
> in, that is he or she can remove the hardlink (dentry) under a publicly shared
> directory which this user doesn't have write permission. Because this user can
> be idnetified as owner of his or her face, and the photo has his face in, he or
> she should have write permission to delete the photo, but no write permission to
> other photos in same category directioy which his or her face is not in.

Well, from what you describe I'd say that the category directories should
just be AI owned rwxrwxrwt dirs (do notice the sticky bit set). This is how
/tmp/ is usually setup. This means that everybody can read the dir,
everybody can delete files but only if they are their owner, everybody can
create files - this is the part you probably don't want but *that* is
pretty easy to restrict by a LSM (practically any one can do this).

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR