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

["Coly Li" <colyli@fnnas.com>]

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