From 51c95fc11727532e3b0d98c8470a6b60907a0680 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 8 Jan 2013 21:31:31 +0100 Subject: IRC. --- .../virtualization/remap_root_translator.mdwn | 97 ++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 open_issues/virtualization/remap_root_translator.mdwn (limited to 'open_issues/virtualization') diff --git a/open_issues/virtualization/remap_root_translator.mdwn b/open_issues/virtualization/remap_root_translator.mdwn new file mode 100644 index 00000000..3cb574ae --- /dev/null +++ b/open_issues/virtualization/remap_root_translator.mdwn @@ -0,0 +1,97 @@ +[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + + +# IRC, freenode, #hurd, 2013-01-05 + + so we have a "remap" root translator? + I mean this: + I'd run my shell in a subhurd whose only difference is that the + root is not the system's root, but my own + which catches accesses to /servers/socket/2 for instance + but leaves the rest flow through the system's root + there is just boot, i don't think it can do that + it'd be useful to have that + it'd be a very useful feature + to use another tcp/ip stack etc. + what happens when translators need to locate other translators + used by the client ? + can't it tell the client to ask the real system's root? + (with the same path) + I don't remember the exact reply name + hum, it's getting too fuzzy for my head :p + well, I mean it's just like translator entries in an ext2fs + ext2fs replies "not me, this one" + but what if e.g. a user has its own pflocal, and when calling + another translator, that one wants to contact the pflocal used by the + client ? + ah, that won't work of course + do we actually have such cases btw ? + procfs perhaps + I don't think we'd want it actually + but isn't that required sometimes ? + inside a shell script, yes + for example, a storeio translator could ask about the priority + properties of the client to proc + but I don't remember a case where an external translator would need + the access + well, that's actually what we want + we don't want to fool the storeio with user-provided data :) + yes + unless the user starts the storeio himself, in which case he will + have to re-root it + so it has to locate the right translator, despite not using the + remap root translator + err, it will already + by just using the system's path + ? + maybe you need to say exactly what "it" and "right" are :) + ok, let's imagine your previous example with a subhurd and pfinet + the remap translator would imply that users from the subhurd + *directly* access all services from the main hurd, except when routed + otherwise by the remap translator to pfinet + by "directly", I mean asking the remap translator, which gives as + answer "not me, the root" + now, what if a translator in the main hurd wants e.g. network + stats from pfinet, it will ask the main one, not the one obtained through + remap + yes + that's completely fine + ah + that's fine if the results don't matter + to get network stats from the user pfinet you'd have to be inside + the shell using the remap translator + otherwise they're inconsistent + yes + I don't see why you'd want to get the pfinet stats from outside + you mean ethernet board usage? + service interactions + i can't think of anything relevant with pfinet + but imagine pflocal and credentials + I believe that'd still be ok + i.e. things outside the remap want to know the actual system things + while things inside want to know the remapped things + and you need that to avoid getting fooled by the user remapping + for credentials, i think it works because the client provides + rights, so it would provide rights to the remapped translators in this + case + this would need to be generalized + I believe it's already general + well no + procfs for example will always talk to the "true" proc server + sure + that's what I want from the outside + if the user, from the inside, wants another view, he'll have to + start another procfs + his own one + ok + attached to the remapping -- cgit v1.2.3