KaiGai, * KaiGai Kohei (kai...@kaigai.gr.jp) wrote: > Please note that all we need to focus on is not pg_xxx_aclcheck() routines > in other words.
I agree, there may be other things which need to move to aclchk.c, and that routine is a good example of something which would be appropriate to move, abstract, and provide an SELinux hook for, in aclchk.c. > The example is not dramatically different from the others, indeed. > But, this code implicitly assume the database superuser can do anyhting, > so the necessary checks are omitted from the code (because they always > return "allowed"). Yes, I realize that's a problem. I don't know that it's a problem which has to be addressed in the first round, but I do believe we will get there. > I think what I should do on the next is ... > - To check up whether it is really possible to implement SELinux's model. > - To describe the list of the security functions in the new abstraction layer. > - To discuss the list of permission at: > > http://wiki.postgresql.org/wiki/SEPostgreSQL_Development#Mandatory_access_controls That sounds like a good approach. As we define the security functions to go into the abstraction layer, I would also say we should identify the exact pieces of existing code which are going to move. Thanks, Stephen
signature.asc
Description: Digital signature
