From 49a086299e047b18280457b654790ef4a2e5abfa Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Wed, 18 Feb 2015 00:58:35 +0100 Subject: Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn" This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1. --- .../virtualization/remap_root_translator.mdwn | 157 +++++++++++++++++++++ 1 file changed, 157 insertions(+) create mode 100644 open_issues/virtualization/remap_root_translator.mdwn (limited to 'open_issues/virtualization/remap_root_translator.mdwn') diff --git a/open_issues/virtualization/remap_root_translator.mdwn b/open_issues/virtualization/remap_root_translator.mdwn new file mode 100644 index 00000000..8f8668fe --- /dev/null +++ b/open_issues/virtualization/remap_root_translator.mdwn @@ -0,0 +1,157 @@ +[[!meta copyright="Copyright © 2013, 2014 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]] + +/!\ [[!tag open_issue_documentation]] Does this completely resolve +[[community/gsoc/project_ideas/server_overriding]]? + + +# 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 + + +## IRC, freenode, #hurd, 2013-01-29 + + ok, the remap translator was too easy + just took fakeroot.c + added if (!strcmp("bin/foo", filename)) filename = + "bin/bash"; in + netfs_S_dir_lookup + and it just works + +[[hurd/interface/dir_lookup]]. + + ok, remap does indeed take my own pfinet + good :) + pfinet's tun seems to be working too + it's however not really flexible, it has to show up in /dev/tunx + I'll have a look at fixing that + yep, works fine + + +## IRC, freenode, #hurd, 2013-02-01 + + braunr: as I expected, simply passing FS_RETRY_REAUTH does the + remapping trick + + +# IRC, freenode, #hurd, 2013-02-12 + + + http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/server_overriding/ + youpi: isn't that your remap translator ? + completely + remap being (5) + + +# IRC, freenode, #hurd, 2013-02-25 + + I'm just having an issue with getcwd getting in the sky + I wonder whether libc might need patching to understand it's in + some sort of chroot + or perhaps remap fixed into avoiding .. of / being odd + erf, it's actually an explicit error + libc just doesn't want to have a ".." / being different from CRDIR + let me just comment out that :) + way better :) + yep, just works fine + + +# IRC, freenode, #hurd, 2013-03-16 + + youpi: is the /bin/remap --help output correct ? + + +# [[hurd/fsysopts]] + +Doesn't support [[hurd/fsysopts]]. -- cgit v1.2.3