This from that PostgreSQL mailing list link you give is interesting:
> AUTH means that the system call is blocked (on that condition variable I mentioned about), and the user mode daemon is asked about the generated event: "postgres, pid 999, open() on file /path/file with flags 0x400003" - something like that. The usermode can either allow or deny the event by replying.
The use of a user mode daemon to make decisions about whether file access is allowed reminds me of the way TOPS-10 on DEC PDP-10 did access control lists over 40 years ago. It's a method I'd like to see for ACLs on modern systems.
On modern systems the ACL is part of the per file metadata. On TOPS-10 the ACL information was in a separate file that contained the ACL information for multiple files. I don't remember if is was one ACL file per user or one per directory.
An ACL entry could specify file name (wildcards allowed), account and group requesting access (wildcards allowed), program that was requesting access, and what kind of access. The wildcards and the centralization of the ACLs for multiple files is what made this system excellent to use.
When an access was attempted the system first checked if it was allowed by the ordinary per file permissions. If it was access was granted and the ACL daemon was not consulted.
If the ordinary permissions denied access and the caller had not set a flag indicating it did not want to check the ACLs the access was denied. If that flag was not set the kernel would consult the access daemon, which would find the ACL file and check the ACLs within to find the ones that applied and make its decision.
> AUTH means that the system call is blocked (on that condition variable I mentioned about), and the user mode daemon is asked about the generated event: "postgres, pid 999, open() on file /path/file with flags 0x400003" - something like that. The usermode can either allow or deny the event by replying.
The use of a user mode daemon to make decisions about whether file access is allowed reminds me of the way TOPS-10 on DEC PDP-10 did access control lists over 40 years ago. It's a method I'd like to see for ACLs on modern systems.
On modern systems the ACL is part of the per file metadata. On TOPS-10 the ACL information was in a separate file that contained the ACL information for multiple files. I don't remember if is was one ACL file per user or one per directory.
An ACL entry could specify file name (wildcards allowed), account and group requesting access (wildcards allowed), program that was requesting access, and what kind of access. The wildcards and the centralization of the ACLs for multiple files is what made this system excellent to use.
When an access was attempted the system first checked if it was allowed by the ordinary per file permissions. If it was access was granted and the ACL daemon was not consulted.
If the ordinary permissions denied access and the caller had not set a flag indicating it did not want to check the ACLs the access was denied. If that flag was not set the kernel would consult the access daemon, which would find the ACL file and check the ACLs within to find the ones that applied and make its decision.