You aren't mistaken, I don't think this type of behavior is included in the spec directly. I think this type of behavior would fall under the filtering section, which would require a filtering strategy definition. There are various strategies for obtaining this kind of functionality technically, however I would advise you to reconsider the urge to add complex querying capabilities before you have explored some semantic solutions.
While I often advocate designers to keep the resource hierarchy as flat as is reasonably possible, in this case you could introduce a family tree sub resource which could semantically define N level of relationships from a particular user, and could even be queried to a particular depth from the user via filtering on a depth constraint.
In this way you could return /user/123/familytree?filter[depth]=2 and return relationships of parent, grandparent, great-grandparent with resource 'objects' or 'resource identifier objects' as desired.
If you are reaching in the bag for a way to carefully sculpt data for a particular concept, there is very likely to be value in creating reusable semantic driven resources to better explain in human terms the relationship between two or more resources.