Re: [TECH TOPIC] re-think of richACLs in AI/LLM era

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

On Wed, Sep 17, 2025 at 09:59:09AM +0800, Jan Kara wrote:
> 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).

This is quite similar to what we are doing now (self-define rules + ebpf hooks)
but your suggestion might be in a more elegant way.

By the above method, our challenges are,
- Application may treat this behavior as a bug
    Once the write/delete access is denied, user application cann't understand
  why the request was rejected. User space application can check permission bits
  and acl, but cannot check the LSM rules, they cannot understand why all
  permission granted but the write/delete access is rejected.
    Currently in our products it is fine, because all applications are written
  by ourself, we know the access deny is from the security rules voilation. But
  in long term this might be a potential challenge.

- Cannot tell the real permission fastly
    From web UI interface, users can click the mouse right button to check his
  or her permission of this specific file or directory. Our current rules-based
  access control needs to reverse iterate all the rules to determine the final
  permission which the user obtains. It is very slow and inconvenient, and we
  don't have proper method to handle the permission display yet.

- Rules store/load/management
    Crrently all the rules are persisted in data base and loaded into in-kernel
  memory table. The rules can be checked very fast and works fine for relative
  small data set and access rules at this moment. But in worst case maybe each
  sharedfile will have a signle rule for its access control, when number of
  shared files and control policies increase more and more, such method doesn't
  scale and is not agile in store/load/management very soon.

This is view from users (both user space developers and end users). Currently I
don't see perfect solution with LSM may solve challenge from view of users.

Thanks for your suggestion.

Coly Li