By "on the group's possessions" I mean "on a separate set of registers that is unique to that user and affects a general sense of 'the group's possessions' which has no meaning unless the group has one or more page(s)."

A grouping looks like this:

user	group	permissions	date
6	76	cadre	2014-08-03 15:45:57

(This says that Izambri is a member of the group for Catacosmos.)

And an entry looks like this:

id	title	subtitle	body	author	template	group	executable	permissions	parent	date	priority
26	Site Infrastructure		<a href="./?">Click here to return to the main page.</a>	1	0	1	0	cadrec-dr-ca-rec—r-	0	2014-01-02 01:17:19	0

(You can see it here if you haven't already.)

The third set of permissions is the group permissions (from left to right: page owner, owner of parent, page group, public users.) In this case, if a user were a member of group 1 (the root group), they would be granted "ca-re" permissions (can read, change body text, and create children pages, but not move, delete, rename, change template etc.) For group permissions to work, both the user's group permission (in the grouping) and the page's group permission (in the entry) must be enabled.

Owner permissions override all other permissions, and public permissions are the 'last resort', but what happens in the middle is a bit more complex: if a user is both the parent owner and a group member, they get added together, giving you both sets of benefits. The main reason for this is to allow you to recursively delete pages (in theory they should delete their children as their own owners) without requiring a special case for group benefits such as an article you're collaborating on.

There's only one case where public permissions are ignored: if you're not logged in, the c, d, and e bits are ignored in the last register. This can be overridden by adding user 0 (anonymous) to a group and assigning pages to that group.