Messages in this thread | | | Date | Tue, 2 Dec 2014 09:26:12 -0800 | From | Greg Kroah-Hartman <> | Subject | Re: Why not make kdbus use CUSE? |
| |
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
| |