Are those use cases heavyweight enough to motivate a new interface? Kyle Moffett <kyle@xxxxxxxxxxxxxxx> wrote: >On Sun, Apr 1, 2012 at 15:03, H. Peter Anvin <hpa@xxxxxxxxx> wrote: >> On 04/01/2012 05:57 AM, Alexey Dobriyan wrote: >>> * /proc/self/fd is unreliable: >>> proc may be unconfigured or not mounted at expected place. >>> Looking at /proc/self/fd requires opening directory >>> which may not be available due to malicious rlimit drop or ENOMEM >situations. >>> Not opening directory is equivalent to dumb close(2) loop except >slower. >> >> This is really the motivation for this... the real question is how >much >> functionality is actually available in the system without /proc >mounted, >> and in particular if this particular subcase is worth optimizing ... >> after all, if someone is maliciously setting rlimit, we can just >abort >> (if someone can set an rlimit they can also force an abort) or revert >to >> the slow path. > >Well, I imagine one typical usecase for closing all FDs is for >security isolation purposes (EG: chroot()+etc), and in a great deal of >chroot environments you don't have /proc available. In particular >/proc has been a source of a lot of privilege escalations in the past, >so avoiding mounting it in a chroot is good security policy if >possible. > >Cheers, >Kyle Moffett -- Sent from my mobile phone. Please excuse my brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
