diff options
Diffstat (limited to 'service_solahart_jakarta_selatan__082122541663/translators_set_up_by_untrusted_users.mdwn')
-rw-r--r-- | service_solahart_jakarta_selatan__082122541663/translators_set_up_by_untrusted_users.mdwn | 583 |
1 files changed, 583 insertions, 0 deletions
diff --git a/service_solahart_jakarta_selatan__082122541663/translators_set_up_by_untrusted_users.mdwn b/service_solahart_jakarta_selatan__082122541663/translators_set_up_by_untrusted_users.mdwn new file mode 100644 index 00000000..ad0187e3 --- /dev/null +++ b/service_solahart_jakarta_selatan__082122541663/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 |