Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn"

This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1.

1 files changed, 583 insertions, 0 deletions

diff --git a/open_issues/translators_set_up_by_untrusted_users.mdwn b/open_issues/translators_set_up_by_untrusted_users.mdwn
new file mode 100644
index 00000000..ad0187e3
--- /dev/null
+++ b/open_issues/translators_set_up_by_untrusted_users.mdwn
@@ -0,0 +1,583 @@
+[[!meta copyright="Copyright © 2011, 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]]
+
+
+# IRC, freenode, #hurd, 2011-07-17
+
+    <antrik> Reventlov: this is the so-called "firmlink issue" -- though AFAIK
+      it doesn't actually apply to firmlinks ;-)
+    <antrik> the problem is that any user can in theory create and set up a
+      special translator, which will redirect to another directory, without any
+      indication that it's a link
+    <braunr> but this doesn't supersede the file system permissions, does it ?
+    <antrik> as a result, if someone runs rm -r on the directory containing
+      that translator (which could be a world-writable one such as tmp), the rm
+      -r will descend into the directory, and thus remove it with the
+      permissions of the user who ran the rm -- not the one who set up the
+      translator
+    <braunr> oh i see, when tmp gets cleared by a script run as root, your home
+      is deleted ?
+    <antrik> right
+    <antrik> of course, the workaround is trivial: just don't follow
+      translators set up by untrusted users
+    <antrik> (which is precisely the default policy for FUSE BTW)
+    <braunr> which is the general policy around memory managers in general
+    <antrik> it's just nobody cared to implement this change
+    <youpi> antrik: does rm use O_NOTRANS ?
+    <antrik> youpi: I'm pretty sure it doesn't
+    <youpi> so it's still an issue for now
+    <antrik> yes, it's still an issue. it's just not a really fundamental
+      problem as macrus claimed it to be... [sigh]
+    <youpi> well, fix rm and then you can say it's not an issue any more
+    <braunr> does it only concern rm ?
+    <antrik> youpi: rm is just an example. the problem is much more generic: a
+      malicious translator can do all kinds of harm
+    <youpi> sure
+    <youpi> it's just about tools not blindly following things
+    <antrik> the only simple and effective answer is not to follow translators
+      from untrusted users by default
+    <youpi> antrik: but then /dev/null can't be non-root
+    <braunr> depends how "untrusted users" are identified
+    <antrik> we discussed a more sophisticated solution with cfhammer, that
+      would change the way reauthentication works in lookups, and should
+      prevent these kinds of permission escalation without preventing desirable
+      uses... but it still wouldn't address DOS issues, so it would be only a
+      partial solution
+    <antrik> youpi: why should it?
+    <manuel> (http://lists.gnu.org/archive/html/bug-hurd/2009-11/msg00231.html
+      for the most sophisticated solution)
+    <antrik> braunr: well, currently the permission system generally trusts
+      root and the own user. implementing something else might be tricky... not
+      sure
+    <antrik> manuel: yes, that's precisely the discussion I was referring
+      to... thanks for the link :-)
+    <youpi> antrik: depends what you mean by "follow"
+    <youpi> what DOS are you thinking of?
+    <antrik> youpi: a translator can generate endless amounts of "data"; a
+      translator can generate endless recursive directory tress; or it can just
+      never return from RPCs... all things that can do pretty much harm
+      depending on the situation
+    <antrik> filesystem clients generally trust filesystem operations to be
+      safe -- and that's just not true anymore with filesystems run by
+      untrusted users
+    <antrik> (be it Hurd translators or FUSE modules)
+    <antrik> this is a fundamental problem as marcus and neal rightly observed
+    <antrik> I just don't agree about the seriousness of the consequences
+    <antrik> I don't think not following untrusted translators really looses us
+      much
+    <youpi> EDOOMANYNEGATIONS
+    <youpi> s/D/T
+    <youpi> again, what do you mean by "following" ?
+    <youpi> always use O_NOTRANS ?
+    <tschwinge> Yes, I think.
+    <youpi> or never accept a REAUTH ?
+    <youpi> O_NOTRANS would mean ftpfs running as root, brrr
+    <youpi> it's not really true that clients always trust filesystem
+      operations
+    <youpi> the "not returning" case for instance, also appears with nfs mounts
+    <antrik> no, not always use O_NOTRANS. just be more selective about what
+      translators to follow. specifically, don't follow translators set up by
+      untrusted users. (unless explicitly requested)
+    <antrik> you can think of it as O_NO_UNTRUSTED_TRANS
+    <antrik> note that if you run ftpfs under a special user, who is not root
+      but trusted by root, this would still be fine. I hope it shouldn't be too
+      hard to implement that...
+    <antrik> as for NFS: clients generally do *not* try to catch possible
+      failures. if the NFS server doesn't return, the clients hang forever. but
+      the NFS server is generally trusted, so this is not much of a problem
+    <antrik> BTW, I guess not accepting reauth from untrusted translators would
+      also fix the privilege escalations (similar to the proposed modified
+      reauth mechanism, only more invasive); but it wouldn't fix the DoS issues
+    <ArneBab> antrik: would that also be an issue for a run translator, which
+      runs a command on read?
+    <ArneBab> youpi: couldn’t ftpfs have root drop priviledges?
+    <ArneBab> like a runas trans
+    <ArneBab> essertially su for translators to drop privs
+    <antrik> ArneBab: hm... if we can make sure that the translator was started
+      as root, and dropped privileges later, I guess that would be fine... not
+      sure how hard that is
+    <antrik> ArneBab: but I think it would be more elegant to start the
+      translators as trusted non-root users in the first place
+    <ArneBab> then i ph.avme to trust them
+    <ArneBab> deper hierarchy
+    <ArneBab> deeper
+    <ArneBab> but essertially the same
+    <ArneBab> if then someone mounted his home himself, would I be able to read
+      it?
+    <ArneBab> /home/user
+    <ArneBab> antrik: if not, that would be really non-nice
+    <antrik> ArneBab: sorry, but we simply *can't* trust a translator set up by
+      an untrusted user. if he controls it, he can make it behave maliciously
+    <antrik> we could in theory try to come up with a proxy that catches
+      problematic semantics, and presents a "safe" variant to the actual
+      clients... but that would be not-trivial, and I'm not sure how safe it
+      can be made
+    <antrik> ArneBab: of course you should always have the option to explicitly
+      say that you want to trust the translator, if you think the user doesn't
+      have malicious intentions :-)
+    <antrik> (I think nsmux would be a good way to achieve this...)
+    <braunr> unless it's really really necessary (and i don't see why it would
+      be), no design should force a process to start with privileges and drop
+      them
+    <braunr> having a set of trusted users (e.g. uid < 100) is a nice solution
+      to the problem imho
+    <braunr> or part of a group, 100 is a non-hurdish static limit
+    <ArneBab> What user is running a passive translator?
+    <braunr> passive translators are a pain for such things :/
+    <braunr> a command line and attach point are not enough to persistently
+      encode the execution context of the tranlator
+    <ArneBab> What user is running a passive translator?
+    <ArneBab> sorry
+    <braunr> the one owning the inode if i'm right
+    <ArneBab> so actually the orly problem are recursive commands, which also
+      are a problem with plain symlinks?
+    <braunr> i'm not sure
+    <ArneBab> Is thene any havoc a translator can wreak that a symlink can’t?
+    <braunr> well, as symlinks are translators, if a translator can damage
+      something, a symlink may too
+    <ArneBab> but not in Linux?
+    <braunr> err
+    <braunr> there are no translator in linux
+    <ArneBab> → commands could just treat translators as symlinks
+    <ArneBab> jepp, but it has symlinks
+    <braunr> no, this would defeat the purpose of translators :p
+    <braunr> and it's just no doable
+    <braunr> you would have recursion everywhere
+    <ArneBab> why?
+    <braunr> because every file access is sent to a translator
+    <ArneBab> hm, yes
+    <braunr> and we don't want to change commands
+    <braunr> we want to fix the design
+    <ArneBab> → only untrusted trans 
+    <braunr> rather than considering them as symlinks, just consider them as
+      untrusted translators
+    <braunr> this doesn't change the semantics, only the action of accessing a
+      node or not
+    <braunr> but as antrik said, this has to be done :)
+    <braunr> the real problem would simplify to "how do you know if a
+      translator can be trusted", which is a matter of selecting the righ
+      identification strategy
+    <braunr> one strong strategy would be to have a port right copied to each
+      trusted task
+    <braunr> i wonder if one of the special ports could be used for that
+    <braunr> or if we have to add a new one
+    <ArneBab> so when I login, I would give port rights to trusted uids?
+    <braunr> no
+    <braunr> when a trusted translator starts a passive translator attached on
+      a node owned by root, it would copy its trusted right to the new task
+    <braunr> much like the device master port is passed to root tasks
+    <braunr> but i'm not sure this mechanism can be safely used to know if the
+      translator can be trusted
+    <braunr> the translator would be able to actively call services requiring
+      this capability
+    <braunr> but i guess client tasks would have to ask for the translator to
+      prove it's trusted
+    <braunr> which is a problem because the issue is to know if it can be
+      trusted before asking it anything
+    <braunr> another way is to register trusted tasks in another server, and
+      ask this server if the target translator is trusted
+    <braunr> i"m pretty sure these strategies already exist in some form on the
+      hurd
+    <ArneBab> hm
+    <braunr> does someone here have an idea why BSD-derived VMs account wiring
+      information at the high level vm_map instead of storing it in lower level
+      vm_page ?
+    <ArneBab> braunr: a translator anywhene in the FS can only be there, if the
+      creator had sufficient rights to the node, right?
+    <ArneBab> so wouldn’t it suffice to check the access rights?
+    <braunr> no
+    <braunr> ismple example: /dev/null is owned by root, but you have read
+      access to it
+    <braunr> hm that may not answer your question actually
+    <braunr> what access right would you check ?
+    <braunr> if someone creates a node with rights 777, do you still want to
+      access it ?
+    <ArneBab> no
+    <braunr> simple enough i hope :)
+    <ArneBab> arg…
+    <ArneBab> if I can write to it, I can give it a translaton
+    <ArneBab> translator
+    <braunr> but this doesn't tell you it can be trusted
+    <ArneBab> well, actually: yes, access, but not recurse
+    <braunr> the owner sets his own rights, and you can't trust the owner
+    <braunr> unless it's root, but you don't want all your translators to run
+      as root
+    <ArneBab> it can act as its owner?
+    <ArneBab> yes
+    <braunr> well, as i told you, a passive translator is started by its parent
+      translator (the one managing the file systeme node it's attached to)
+    <braunr> the new translator runs as the user owning the node
+    <braunr> (if i'm right)
+    <ArneBab> …and so on, till noot starts the first
+    <ArneBab> root
+    <braunr> ?
+    <ArneBab> root starts /, right?
+    <braunr> no
+    <braunr> gnumach starts /
+    <ArneBab> ah, right
+    <braunr> gnumach starts somefs.static
+    <braunr> which attaches at /
+    <braunr> and runs with root privileges
+    <braunr> keep in mind that unix permissions are implemented as capabilities
+      on the hurd
+    <ArneBab> → root has it / it’s root
+    <braunr> the rights you have aren't limited to those permissions
+    <ArneBab> jepp
+    <braunr> and it's not "until"
+    <ArneBab> so why should I not access a translator run by someone else? I
+      just don’t want to do any active command (recurse)… hm… can a translator
+      turn a read request into a write?
+    <braunr> that's the only problem
+    <ArneBab> program with my rights wants to read, but the translator makes it
+      write instead?
+    <braunr> no
+    <braunr> a translator can do pretty much anything with your request
+    <ArneBab> with my rights?
+    <braunr> no
+    <braunr> the most obvious example of DoS is simply not answering
+    <braunr> your process hangs
+    <braunr> considering some file system accesses, a translator could return
+      inconsistent data
+    <ArneBab> so if the translator tries to make me write instead of read, it
+      can do so only when the owner of the translaton can write to the file in
+      question?
+    <braunr> a well written application shouldn't have too much trouble dealing
+      with it but some aren't that well written
+    <braunr> this has *nothing* to do with read/write permissions
+    <braunr> you should read the critique :p
+
+[[hurd/critique]]
+
+    <ArneBab> ln -s /home/you /home/me → “why don’t you look into my home?”
+    <ArneBab> read it again, that is :)
+    <ArneBab> (has been some time since I read it)
+    <antrik> braunr: you just described the auth mechanism ;-)
+    <antrik> ArneBab: symlinks can do considerably less than translators; and
+      even these caused a lot of trouble when introduced (and still cause
+      sometimes)
+    <antrik> we can't make every application aware of translators
+    <antrik> indeed I believe we can a avoid many problems by presenting
+      various translators as symlinks -- but this is not approriate for all
+      translators
+    <antrik> it is something the translator itself decides, so it's not helpful
+      to solve security issues at all
+    <antrik> and as braunr already pointed out, this wouldn't help with DoS
+      problems
+
+
+# Linux kernel, Symlink/Hardlink Attack
+
+Even though not directly comparable, the issues described at [Symlink
+Protection](https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Symlink_Protection)
+and [Hardlink
+Protection](https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Hardlink_Protection)
+do bear some similarity with the issue we're discussing here.
+
+Likewise, Kees Cook, [fs: symlink restrictions on sticky
+directories](http://lwn.net/Articles/468215/), 2011-11-18.  [2011-12-06
+update](http://lwn.net/Articles/470891/).  Jake Edge, [Fixing the symlink race
+problem](http://lwn.net/Articles/472071/), 2011-12-14.
+
+
+# IRC, freenode, #hurd, 2011-08-31
+
+    <antrik> I don't see any problems with following only translators of
+      trusted users
+    <youpi> where to store the list of trusted users?
+    <youpi> is there a way to access the underlying node, which for /dev
+      entries belongs to root?
+    <ArneBab> youpi: why a list of trusted users? Does it not suffice to
+      require /hurd/trust set by root or ourselves?
+    <youpi> ArneBab: just because that's what antrik suggests, so I ask him for
+      more details
+    <ArneBab> ah, ok
+    <antrik> youpi: probably make them members of a group
+    <antrik> of course that doesn't allow normal users to add their own trusted
+      users... but that's not the only limitation of the user-based
+      authentication mechanism, so I wouldn't consider that an extra problem
+    <antrik> ArneBab: we can't set a translator on top of another user's
+      translator in general
+    <antrik> root could, but that's not very flexible...
+    <antrik> the group-based solution seems more useful to me
+    <ArneBab> antrik: why can’t we?
+    <antrik> also note that you can't set passive translators on top of other
+      translators
+    <antrik> ArneBab: because we can only set translators on our own nodes
+    <ArneBab> active ones, too?
+    <antrik> yes
+    <ArneBab> antrik: I always thought I could…
+    <ArneBab> but did not test it
+    <ArneBab> antrik: so I need a subhurd to change nodes which do not belong
+      to me?
+    * ArneBab in that case finally understands why you like subhurds so much:
+        That should be my normal right
+    <antrik> it should be your normal right to change stuff not belonging to
+      you? that's an odd world view :-)
+    <antrik> subhurds don't really have anything to do with it
+    <ArneBab> change it in a way that only I see the changes
+    <antrik> you need local namespaces to allow making local modifications to
+      global resources
+    <youpi> it should be one's normal right to change the view one has of it
+    <antrik> we discussed that once actually I believe...
+    <antrik> err... private namespaces I mean
+
+IRC, freenode, #hurd, 2011-09-10:
+
+    <cjuner_> I am rereading Neal Walfield's and Marcus Brinkman's critique of
+      the hurd on mach. One of the arguments is that a file system may be
+      malicious (by DoS its clients with infinitely deep directory
+      hierarchies). Is there an answer to that that does not require programs
+      to be programmed defensively against such possibilities?
+
+IRC, freenode, #hurd, 2011-09-14:
+
+    <antrik> cjuner: regarding malicious filesystems: the answer is to do
+      exactly the same as FUSE on Linux: don't follow translators set up by
+      untrusted users by default
+    <cjuner> antrik, but are legacy programs somehow protected? What about
+      executing `find`? Or is GNU's find somehow protected from that?
+    <antrik> cjuner: I'm talking about a global policy
+    <cjuner> antrik, and who would implement that policy?
+    <antrik> cjuner: either glibc or the parent translators
+
+Continued discussion about [[resource_management_problems/pagers]].
+
+
+# IRC, freenode, #hurd, 2013-02-24
+
+    <braunr> on a more general topic, i've been thinking about client and
+      server trust
+    <braunr> there have been many talkbs about it regarding l4/coyotos/hurdng
+    <youpi> I generally think the client can trust the server
+    <braunr> and passing the select timeout to servers corroborates this
+    <youpi> because it's either root, or it's the same user
+    <braunr> hum yes, but that's not exactly my question, you'll see
+    <braunr> there is one feature the hurd has, and i'm not sure we should have
+      it considering what it requires
+    <braunr> the feature is that clients can, at any time, "break" from a
+      server
+    <youpi> "break" ?
+    <braunr> the current implementation is to cancel the current RPC after 3
+      seconds without a reply when the user sends SIGINT
+    <braunr> the problem is that, moving to a complete migrating thread model
+      would make that impossible (or very complicated to do right)
+
+[[mach_migrating_threads]].
+
+    <braunr> would it be ok to remove this feature ?
+    <youpi> well, we need to have SIGINT working, don't we?
+    <braunr> obviously
+    <braunr> but that's not what the feature is meant to do
+    <braunr> it allows clients to recover from a server that misbehaves and
+      doesn't return
+    <youpi> then I don't understand in enough details what you mean :)
+    <braunr> imagine a buggy driver in linux that gets into an uninterruptible
+      sleep
+    <braunr> you can't even kill your process
+    <braunr> that's what the feature is meant to solve
+    <youpi> that's a quite useful thing
+    <youpi> e.g. stuck nfs etc., it's useful to be able to recover from that
+    <braunr> forbidding uninterruptible sleeps would also be a solution, but
+      then it means relying on servers acting right
+    <braunr> which is why i mention we usually trust servers
+    <youpi> well, there is "trust" and "trust" :)
+    <youpi> i.e. security-wise and robustness-wise
+    <youpi> I meant clients can usually trust servers security-wise
+    <braunr> my current idea for x15 is to forbid this kind of breaking, but
+      also forbid uninterruptible sleeps
+    <youpi> robustness-wise, I'd say no
+    <braunr> this way, sending a signal directly reaches the server, which is
+      trusted to return right away (well, conforming to the handling behaviour)
+    <braunr> so yes, buggy servers would prevent that, but on the other hand,
+      stuck nfs wouldn't
+    <youpi> provided the nfs implementation is not bogus
+    <braunr> yes
+    <youpi> I'd tend to agree, but would rather see this discussed on the list
+    <braunr> yes
+    <braunr> actually, it wouldn't be that hard to keep the current behaviour,
+      since i won't implement true migrating threads
+    <braunr> but it means retaining some issues we have (most importantely,
+      denial of service)
+    <braunr> -e
+    <braunr> what i want to avoid is
+      http://www.gnu.org/software/hurd/hurd/ng/cancellationforwarding.html
+    <youpi> for non-trusted servers, we could have a safety wrapper
+    <youpi> which we trust and does things carefully when talking with the
+      non-trusted server
+    <braunr> what would a non trusted server be ?
+    <youpi> whatever is neither root nor me
+    <youpi> e.g. nobody-provided /ftp:, or $HOME of another user, etc.
+    <braunr> i'd argue we don't talk to non trusted servers at all, period
+    <youpi> users won't like it :)
+    <braunr> and i'd extend root to a system provided list
+    <youpi> actually the nobody /ftp: case is important
+    <braunr> users should be able to create their own list of trusted users
+    <youpi> it's also the nobody /dev/null case
+    <youpi> atm it's root
+    <braunr> yes
+    <braunr> i see the point
+    <braunr> i'm just saying the idea of "using non-trusted server" doesn't
+      make sense
+    <youpi> actually running /ftp: under nobody is dangerous
+    <youpi> since if you're running as nobody (because you broke into the
+      system or whatever), then you can poke with nobody-provided servers
+    <braunr> yes
+    <youpi> so we'd rather have really-nobody processes
+    <braunr> taht's an already existing problem
+    <youpi> which can't be poked into
+    <youpi> (and thus can't poke into each other)
+    <braunr> or a separate user for each
+    <youpi> that'd be difficult
+    <braunr> or separate tokens, it's not important
+    <youpi> for /ftp:/ftp.debian.org used by someone, and /ftp:/ftp.foo.org
+      used by someone else
+    <braunr> what i mean is that, by talking to a server, a client implicitely
+      trusts it
+    <braunr> youpi: wouldn't that just be the same "ftp" user ?
+    <youpi> ideally, a carefully-crafted client could avoid having to trust it
+    <braunr> really ?
+    <youpi> braunr: that's the problem: then each ftpfs can poke on each other
+    <braunr> well, each global one
+    <youpi> there's the daemon-sharing issue too, yes
+    <braunr> i wasn't thinking about ftpfs, but rather the "system" pfinet for
+      example
+    <youpi> like /dev/null is shared
+    <braunr> when you say root or me, it's "system" or me
+    <braunr> by default, users trust their system
+    <braunr> they don't trust other users
+    <youpi> avoid having to trust it: yes, by using timeouts etc.
+    <braunr> that's clearly not enough
+    <youpi> why?
+    <braunr> shapiro described this in a mail but i can't find it right now
+    <youpi> I wouldn't like to have to trust ftpfs
+    <braunr> well time is one thing, data provided for example is another
+    <braunr> well, you do
+    <youpi> who knows what bug ftpfs has
+    <youpi> ideally I would be able not to have to
+    <youpi> braunr: you can check data
+    <braunr> i don't think that ideal is possible
+    <braunr> it you set a ftp translator with a user account, you give it the
+      password
+    <youpi> which password?
+    <braunr> the account password
+    <youpi> which account?
+    <braunr> "a user account"
+    <braunr> i.e. not anonymoius
+    <youpi> ah
+    <youpi> well, sure, you have to give that to ftpfs
+    <youpi> I mean the ftp server might be malicious or whatever
+    <youpi> and trigger a bug in ftpfs
+    <braunr> yes
+    <youpi> so I don't want to have to trust ftpfs
+    <braunr> what would that mean in practice ?
+    <youpi> have a trusted translation layer which papers over it, checking
+      timeouts & data
+    <braunr> how do you check data ?
+    <youpi> by knowing the protocol
+    <braunr> ?
+    <braunr> can you give a quick example ?
+    <youpi> well, which data check do you need?
+    <youpi> (it's you who mentioned data issues :) )
+    <braunr> i don't know what you mean by that so, choose as you see fit
+    <braunr> well the password one for example
+    <braunr> i was merely saying that, buy using an application, be it a
+      regular one or a translator, you automatically trust it
+    <youpi> you mean the ftp user password ?
+    <braunr> it becomes part of your tcb
+    <youpi> of course you have to provide it to ftpfs
+    <youpi> that's not a problem
+    <youpi> yes, but it's not because you connect to an http website that you
+      trust the webserver on the other end
+    <youpi> your web browser does checking for you
+    <braunr> when the protocol allows it
+    <braunr> (in this case, i'm thinking assymmetrical cryptography)
+    <youpi> in which case example doesn't it ?
+    <youpi> it seems we're not talking about the same kind of issue, thus not
+      understanding each other
+    <braunr> indeed
+    <youpi> by "trusting", I don't mean "be sure that it's the right server at
+      the other end"
+    <braunr> my point is that not trusting a server is impossible
+    <youpi> I mean "it behaves correectly"
+    <braunr> yes
+    <braunr> it may not behave correctly, and we might not know it
+    <youpi> as long as it doesn't make the program crash, that's fine
+    <youpi> that's what I mean
+    <braunr> that's where the difference is
+    <youpi> but giving the password is not my concern here
+    <youpi> and giving the password is a matter of cryptography, etc.  yes, but
+      that's completely not my point
+    <braunr> i'm concerned about absolute correct behaviour 
+    <braunr> hm
+    <braunr> no actually i was
+    <braunr> but not any more, the discussion has shifted back to the timeout
+      issue
+    <braunr> ah no, i remember
+    <braunr> we talked about which servers to trust
+    <braunr> and how to alter communication accordingly
+    <braunr> and my point was that altering communication shouldn't be done, we
+      either trust the server, and talk to it, or we don't, and we stay away
+    <braunr> the wrapper would help for this specific blocking issue, yes
+    <youpi> I don't agree on this
+    <youpi> let me take a way more simple example
+    <youpi> a server that provides data through io_read
+    <youpi> I don't want to trust it because it's provided by some joe user
+    <youpi> but I still want to have a look at the data that it produces
+    <youpi> I'm fine that the data may be completely non-sense, that's not a
+      problem
+    <youpi> what is a problem, however, is if the hexdump program I've run over
+      it can't be ^C-ed
+    <braunr> yes, that's the specific issue i mentioned
+    <youpi> and for that, a mere trusted intermediate could be enough
+    <braunr> iirc, there is a firmlink-related issue 
+    <youpi> ?
+    <braunr>
+      http://www.gnu.org/software/hurd/open_issues/translators_set_up_by_untrusted_users.html
+    <youpi> I'm not able to guess what conclusion you are drawing here :)
+    <braunr> don't talk to untrusted servers
+    <youpi> or be careful
+    <youpi> the rm -fr /tmp being aabout being careful actually
+    <braunr> right
+    <braunr> i have a very unix-centric view for my system actually
+    <braunr> i think posix compatibility is very important for me
+    <braunr> more than it seems to have been in the past when the hurd was
+      designed
+    <braunr> to* me
+    <braunr> so i don't trust tools to be careful
+    <youpi> that's why a wrapping translator could make it back to posix
+      compatibility
+    <braunr> but i see what you mean
+    <youpi> being careful for the tools
+    <braunr> hum, a wrapping _translator_ ?
+    <youpi> yes, similar to remap and fakeroot
+
+[[virtualization/remap_root_translator]], [[virtualization/fakeroot]].
+
+    <braunr> ok
+    <youpi> you'd tell it "for this path, please be careful for my tools"
+    <braunr> ok so
+    <braunr> it would basically still end up trusting system or me
+    <braunr> but you'd add this wrapper to the system
+    <youpi> "it" ?
+    <braunr> the situation
+    <braunr> i don't know :)
+    <braunr> the implementation, whatever
+    <youpi> the shell I'm running, you mean
+    <braunr> and it would be the job of this translator to shield the user
+    <youpi> yes
+    <braunr> that's a good idea, yes
+    <youpi> it could reduce the allowed RPC set to what it knows to check
+    <braunr> how would the shell use it ?
+    <braunr> would it "shadow" / ?
+    <youpi> yes
+    <braunr> ok