path: root/open_issues/translators_set_up_by_untrusted_users.mdwn

[[!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