rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn

1 files changed, 0 insertions, 583 deletions

diff --git a/open_issues/translators_set_up_by_untrusted_users.mdwn b/open_issues/translators_set_up_by_untrusted_users.mdwn
deleted file mode 100644
index ad0187e3..00000000
--- a/open_issues/translators_set_up_by_untrusted_users.mdwn
+++ /dev/null
@@ -1,583 +0,0 @@
-[[!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