Created attachment 101531 [details] Use xmlto with --noextensions to prevent writing to /proc/self/coredump_filter by Java JRE This is coming from, http://forums.gentoo.org/viewtopic-p-7572588.html 1-liner fix: sed -i -e 's:$(XMLTO):& --noextensions:' doc/Makefile.am Attaching patch that does same. Run xmlto with --noextensions parameter since it's not required for dbus documentation to use the java based `fop` xmlto tries to automatically use. It's because Java likes to have *write* access to /proc/self/coredump_filter and it's problematic because if you are a packager for a distributino or a source based distribution user, the sandbox[1] prevents writing to /proc/self/coredump_filter for safety reasons by default. Note that there was a broken xmlto release, 0.0.25 (and perhaps some older ones) that prevented use of --noextensions even while --help showed it, so this patch requires unbroken 0.0.26. But that's something distributions should worry about, it's not dbus's fault if someone uses broken xmlto. [1] http://www.gentoo.org/proj/en/portage/sandbox/ I figured this is suitable for upstream inclusion :-)
For reference, `fop` is this http://xmlgraphics.apache.org/fop/ and xmlto has automagic code to it, and upstream of xmlto has said to apply --noextensions to skip it where required.
(This is not Gentoo -specific, other distributions use sandbox or some other type of jails too)
Hmm. For some reason it's still accessing `fop` and this patch doesn't really solve the problem. I'll close this. And, the more I think about it, this isn't really dbus problem to begin with, and should be solved either in java or in sandbox directly.
Not a bug in dbus, not a bug in xmlto, not a bug in fop. This is Java JRE, Icedtea 7.x writing to /proc/self/coredump_filter and Sandbox preventing it, so yeah, I don't know what I was thinking opening this here. :-p
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.