Re: thread ids, task ids and subsystems

[Maurizio Boriani]

>>>>> "Marcus" == Marcus Brinkmann <address@hidden> writes:

    Marcus> On Tue, Apr 08, 2003 at 09:59:40PM +0200, Niels Möller
    Marcus> wrote:

    Marcus> The issues as I see them are the following:

    Marcus> * Do we make use of the port/handle concept in the task
    Marcus> server or not?  I originally wanted to start off without
    Marcus> this, because you said (correctly) that it is desirable to
    Marcus> be able to use the task server in other, non hurdish
    Marcus> systems, too, and because having (nr of processors)
    Marcus> handles is overkill.  But when we talk about
    Marcus> non-privileged users calling on the task server directly
    Marcus> (which should be possible if we don't want to route
    Marcus> everything through proc via proc ports/handles), then we
    Marcus> need an "authentication" mechanism in the task server, and
    Marcus> that would basically be identical to the port/handle
    Marcus> system.  So, I concluded that yes, we do need the
    Marcus> port/handle concept in the task server.  If we need it
    Marcus> only for tasks or also for threads I don't know yet.
    Marcus> Performance isn't hurt so bad.  I would like to ensure
    Marcus> that rpcs for the same task are very quick (as they can be
    Marcus> authenticated by comparing the senders task id in the
    Marcus> version field of the thread id with the task id the rpc is
    Marcus> sent to).  Tasks sending RPCs to other task ports might be
    Marcus> a wee bit slower because you need to verify if that is
    Marcus> allowed by looking it up in a hash or list of some sort.
    Marcus> But usually tasks don't keep other tasks task port, so
    Marcus> usually that wouldn't be a problem.

I'had few idea after afternoon (post eat) "otium":
        * task server could route rpc from a task to another one in totally
                free and leave decision to accept or deny request to 
                destination task. So task server will act like a router in 
                an ip network: route all and the destination should protect
                himself.
        * like a router the task server could have some policies (defined by a
                privileged task) which filter rpc from a task to another one.
But to do this a destination task should be able to do some "query" to the 
sender one (who is the user who generate you? or some similar) in order to 
identify it (but only once, and after could be cached). 

About task manipulation issue, the source task could gently ask to destination
task to murder himself and destination task could do or don't execute the 
request. The task server could obviously do everything on all created task.

So could be needed an auth server (or acl server) which dispatch and verify
credentials like a simplified krb and store policies.

These are only fool adea or could work?
In this way port concept should be th rowed out.

    Marcus> * Accounting ids are then free to be just that, and used
    Marcus> for accounting.  That means accounting the tasks resources
    Marcus> as well as some sort of task relationship.  I will take a
    Marcus> look at other systems accounting interfaces to see what
    Marcus> "standards" already exist and which features are
    Marcus> desirable.  We can then decide how accounting ids are
    Marcus> given out.  I imagine this: Usually login would set the
    Marcus> initial user task to the accounting id of the user.  This
    Marcus> can be made a bit more flexible by splitting the
    Marcus> accounting id into a system part and a user part, and let
    Marcus> users set the user part freely.  This way a user could
    Marcus> implement some sort of sub-accounting without much work.
    Marcus> This would probably only be really useful if the user
    Marcus> would be allowed to set resource limits for such
    Marcus> subaccount ids.  Maybe subaccounts are not really useful
    Marcus> and users should have to use proxy servers to achieve
    Marcus> that.

as said above ids could be the auth server itself which track who is 
running what and privileges

    Marcus> So much for now.

agree

    Marcus> Thanks, Marcus

Thanks,
baux


-- 
Maurizio Boriani
GPG key: 0xCC0FBF8F
fingerprint => E429 A37C 5259 763C 9DEE  FC8B 5D61 C796 CC0F BF8F <= fingerprint