summaryrefslogtreecommitdiff
path: root/open_issues/virtualization/remap_root_translator.mdwn
diff options
context:
space:
mode:
authorSamuel Thibault <samuel.thibault@ens-lyon.org>2015-02-18 00:58:35 +0100
committerSamuel Thibault <samuel.thibault@ens-lyon.org>2015-02-18 00:58:35 +0100
commit49a086299e047b18280457b654790ef4a2e5abfa (patch)
treec2b29e0734d560ce4f58c6945390650b5cac8a1b /open_issues/virtualization/remap_root_translator.mdwn
parente2b3602ea241cd0f6bc3db88bf055bee459028b6 (diff)
Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn"
This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1.
Diffstat (limited to 'open_issues/virtualization/remap_root_translator.mdwn')
-rw-r--r--open_issues/virtualization/remap_root_translator.mdwn157
1 files changed, 157 insertions, 0 deletions
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
+
+ <youpi> so we have a "remap" root translator?
+ <youpi> I mean this:
+ <youpi> I'd run my shell in a subhurd whose only difference is that the
+ root is not the system's root, but my own
+ <youpi> which catches accesses to /servers/socket/2 for instance
+ <youpi> but leaves the rest flow through the system's root
+ <braunr> there is just boot, i don't think it can do that
+ <youpi> it'd be useful to have that
+ <youpi> it'd be a very useful feature
+ <youpi> to use another tcp/ip stack etc.
+ <braunr> what happens when translators need to locate other translators
+ used by the client ?
+ <youpi> can't it tell the client to ask the real system's root?
+ <youpi> (with the same path)
+ <youpi> I don't remember the exact reply name
+ <braunr> hum, it's getting too fuzzy for my head :p
+ <youpi> well, I mean it's just like translator entries in an ext2fs
+ <youpi> ext2fs replies "not me, this one"
+ <braunr> 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 ?
+ <youpi> ah, that won't work of course
+ <braunr> do we actually have such cases btw ?
+ <braunr> procfs perhaps
+ <youpi> I don't think we'd want it actually
+ <braunr> but isn't that required sometimes ?
+ <youpi> inside a shell script, yes
+ <braunr> for example, a storeio translator could ask about the priority
+ properties of the client to proc
+ <youpi> but I don't remember a case where an external translator would need
+ the access
+ <youpi> well, that's actually what we want
+ <youpi> we don't want to fool the storeio with user-provided data :)
+ <braunr> yes
+ <youpi> unless the user starts the storeio himself, in which case he will
+ have to re-root it
+ <braunr> so it has to locate the right translator, despite not using the
+ remap root translator
+ <youpi> err, it will already
+ <youpi> by just using the system's path
+ <braunr> ?
+ <youpi> maybe you need to say exactly what "it" and "right" are :)
+ <braunr> ok, let's imagine your previous example with a subhurd and pfinet
+ <braunr> 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
+ <youpi> by "directly", I mean asking the remap translator, which gives as
+ answer "not me, the root"
+ <braunr> 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
+ <braunr> yes
+ <youpi> that's completely fine
+ <braunr> ah
+ <braunr> that's fine if the results don't matter
+ <youpi> to get network stats from the user pfinet you'd have to be inside
+ the shell using the remap translator
+ <braunr> otherwise they're inconsistent
+ <braunr> yes
+ <youpi> I don't see why you'd want to get the pfinet stats from outside
+ <youpi> you mean ethernet board usage?
+ <braunr> service interactions
+ <braunr> i can't think of anything relevant with pfinet
+ <braunr> but imagine pflocal and credentials
+ <youpi> I believe that'd still be ok
+ <youpi> i.e. things outside the remap want to know the actual system things
+ <youpi> while things inside want to know the remapped things
+ <youpi> and you need that to avoid getting fooled by the user remapping
+ <braunr> for credentials, i think it works because the client provides
+ rights, so it would provide rights to the remapped translators in this
+ case
+ <braunr> this would need to be generalized
+ <youpi> I believe it's already general
+ <braunr> well no
+ <braunr> procfs for example will always talk to the "true" proc server
+ <youpi> sure
+ <youpi> that's what I want from the outside
+ <youpi> if the user, from the inside, wants another view, he'll have to
+ start another procfs
+ <youpi> his own one
+ <braunr> ok
+ <youpi> attached to the remapping
+
+
+## IRC, freenode, #hurd, 2013-01-29
+
+ <youpi> ok, the remap translator was too easy
+ <youpi> just took fakeroot.c
+ <youpi> added if (!strcmp("bin/foo", filename)) filename =
+ "bin/bash"; in
+ <youpi> netfs_S_dir_lookup
+ <youpi> and it just works
+
+[[hurd/interface/dir_lookup]].
+
+ <youpi> ok, remap does indeed take my own pfinet
+ <youpi> good :)
+ <youpi> pfinet's tun seems to be working too
+ <youpi> it's however not really flexible, it has to show up in /dev/tunx
+ <youpi> I'll have a look at fixing that
+ <youpi> yep, works fine
+
+
+## IRC, freenode, #hurd, 2013-02-01
+
+ <youpi> braunr: as I expected, simply passing FS_RETRY_REAUTH does the
+ remapping trick
+
+
+# IRC, freenode, #hurd, 2013-02-12
+
+ <braunr>
+ http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/server_overriding/
+ <braunr> youpi: isn't that your remap translator ?
+ <youpi> completely
+ <youpi> remap being (5)
+
+
+# IRC, freenode, #hurd, 2013-02-25
+
+ <youpi> I'm just having an issue with getcwd getting in the sky
+ <youpi> I wonder whether libc might need patching to understand it's in
+ some sort of chroot
+ <youpi> or perhaps remap fixed into avoiding .. of / being odd
+ <youpi> erf, it's actually an explicit error
+ <youpi> libc just doesn't want to have a ".." / being different from CRDIR
+ <youpi> let me just comment out that :)
+ <youpi> way better :)
+ <youpi> yep, just works fine
+
+
+# IRC, freenode, #hurd, 2013-03-16
+
+ <braunr> youpi: is the /bin/remap --help output correct ?
+
+
+# [[hurd/fsysopts]]
+
+Doesn't support [[hurd/fsysopts]].