Creating and querying a database to set hierarchical associations between Groups, Users, Items and Points
I think your approach - in having 3 joining tables (Point_group, Point_user, Point_item) is sound.

The considerations of this design are:


Adding "permission" is easy enough - if the user selects to add to User, then you insert into Point_user
Starting with a Point, if you want to ask "Which Groups, Users and Items have permission?" then you will need to construct a query against all 3 joining tables. You could have 3 separate queries and aggregate results in your application, or you could have a single query which is the UNION of 3 SELECTs (with a column representing the SELECT that includes a row, with values like user, etc)
If you want to start with a Group, User or Item, and ask "Which points are permitted for this Group/User/Item?" then your query gets more complicated the lower down you go. For example - if you start with an Item, you have to query Point_item for all rows having the ID of the Item. You also have to find all linked User rows - and for each of those rows, check Point_user. Likewise, you then have to find all linked Group rows and then search Point_group for all matches. In straight SQL this will be a large SELECT - but that may be totally fine - it's just something to think about.


To come at this another way - what alternatives do you have?


You could have a single table that somehow maps permissions from a Point to other objects. Its design would have point_id, of course, and then a column to specify what it is that this Point is mapping to - ie. Group, User, or Item. Then, of course, you need an id column - which would link to the relevant table.


I have seen models such as this alternative implemented before, and quite frankly, I think that's a worse design. Such a design means that when you want to join from your Point to the other entity, you need to check this mapping flag column in order to make a decision about which table should be joined. It's messy, ugly and performance intensive.

There is one further alternative, however:


Merge your Group, User and Item tables into a single table. For want of a better name, call it Entity, in this example. You now need a flag to indicate the type of entity on a given row - such as Group, User and Item. You will also want a column to specify parent - so that for an Item row you can specify its User parent. 


This last suggestion would mean you only need a single mapping table between Entity and Point. However, run through all of the above scenarios again - how will you query this if you start with, say, a Point, and want to know which Groups, Users and Items have permission to view? Getting a list of all entities would be a simple query, but if you want to list all members of all entities, you would need the entity table to join itself multiple times.

This last design may have its benefits, but I think your original proposal is the easiest to maintain and understand.