Does this completely resolve 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
<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 ?
Doesn't support fsysopts.