On Tue, Dec 02, 2014 at 07:22:11AM -0500, Richard Yao wrote: > Assuming that this dance succeeds, the FUSE process could then make a > readonly file in itself, open it read only, unlink it, put the data into > the file and send the file descriptor via UNIX domain socket while > refusing further writes. If it has its own user/group, the file should > be safe from prying eyes. > > This is not as good as a memfd and also suffers from the race that > O_TMPFILE was meant to close, but it should be able to function as a > decent fallback. We can't knowingly create and advocate for broken code, sorry. > This would preserve portability across not only > different versions of Linux, but also other POSIX systems. I honestly do not care about any other system than Linux, so I don't see why this would ever be an issue. > Keeping the code in userspace would allow us to apply SELinux policies > to it, which is something that we would lose if it were go to into the > kernel. On the contrary, the kdbusfs implementation gives you better security model support than before, it ties directly into the LSM hooks, see the add-on patches from some other developers that bring full support of LSM to the codebase. > That said, it is still not clear to me that dbus must be inside the > kernel to be able to perform multicast and zero copy using memfd. It seems you have yet to read my introductory email for the patch series. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
