What is the best way to form an Access List in SQL?

Question

SQL

There is some spherical application that works with SQL.
Users are pre-authorized in it and can interact with some list of tables.
There is a task to make a certain ACL with groups, which will determine which tables and which columns a member of the group can edit, read, etc.
How in that case it is more correct to form Access List?
1 - Keep a table with groups, keep one more table for each table, with a list of groups and which of the groups can do what.
2 - Keep a table with groups, and for each group have its own table with a list of tables where permissions are registered.
3 - Anything else?

Answer 1

You have functionality in the application, you can simply prohibit doing something inside it, for example, prohibiting the use of any entity. You will need to store a table with groups and a table with access rights, roughly speaking, 1 row in the rights table contains a foreign key to a table with a group, and let's say 2 more columns boolean allow / deny and an object or entity. Now, when accessing an object, you will have to check if the user belongs to a group or join groups by keys with a table of rights with a filter by the name of the object, sorted by deny so that it is at the top, and you read from the top, if you find deny - it means a ban, if you find allow - allow, found nothing - ban.

Answer 2

If your application does not have to work with many different DBMS, then it might be better to rephrase the question to:
"Which DBMS allows you to restrict read-modify-delete access to tables up to issuing such permissions at the level of individual fields of tables?".
For example, MSSQL (and others) has been doing this by standard means for a long time.
You can pull this data from service tables or through built-in procedures.
And the DBMS, of course, controls the rules you entered.
If you want to make your own. Then model it in tables and then normalize:
Users
Groups
Roles (Administrator, Read-only, Guest ...)
Database object reference (reference: table, stored procedure, table field ...)
DB objects (table name, table field name with a link to the same table, stored procedure parameter ...)
Object properties (fields, parameters of stored procedures)
Directory of operations on objects (starting stored procedures, deleting a record in a table, modifying a table FIELD . ..)
Operations on objects (to which role is attached which operation from the directory + on which object)
Audit log (Who, What, When - links to the User, Object and Operation + date).
etc.