ambiguous services of children

[Norman Feske]

Hi David,

> thanks for the detailed answer. I considered your hint regarding the
> trustworthiness of the clients: now the parent is providing the service
> to its children.works like a charm! the slave approach also worked, but
> i think the reversed way is more elegant. i should have thought of that
> earlier ;)

great that you found this consideration worthwhile. :-)

> in the next step, the parent shall process the calls from its client.
> thus, its necessary that the parent knows the label of the child which
> issued the call. The child sets its label in
> Child_policy::filter_session_args(...). my question is: how does the
> parent obtain these session arguments ?

The child creates the connection to your service by invoking the
'Parent::session' RPC call. The parent-side 'Child' object handles this
request by calling 'Child_policy::resolve_session_request' with the
session arguments as parameter. The label is just a part of the session
arguments. By overriding this virtual function, you can monitor the
arguments including the label.

Btw, the 'Child_policy::filter_session_args' function is not called by
the child process but by the 'Child' object in the parent process. The
terminology is a bit confusing: The 'Child' class represents the child
inside the parent process.

However, addressing your actual problem, I recommend to not distinguish
the children based on the labels supplied by themselves. A misbehaving
child could forge the label and thereby trick the parent to do wrong
things. The natural way to tell the origins of different requests apart
is to hand out different sessions to each child. So when a child asks
for session, hand out the child-specific session. E.g., you could host
the respective 'Session_component' object as member of your child/policy
class. So later, when a request comes in, it is dispatched in the
context of the right session (that is associated with one particular child).

> maybe there is another ( better? ) way to obtain the childs name? 

Actually, child processes don't know their own names. Sticking a name to
a child (or not) is entirely up to the parent. In the case of the init
process, the assigned name is used to prefix the "label" session
argument of each session originating from the child with the child's
name. But that is just an option. You don't have to do that.

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth