Bug 207209
| Summary: | textproc/kibana4 /usr/local/www/kibana43 ownership and permissions | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Athanasios Douitsis <aduitsis> | ||||||||||
| Component: | Individual Port(s) | Assignee: | freebsd-ports-bugs (Nobody) <ports-bugs> | ||||||||||
| Status: | Closed FIXED | ||||||||||||
| Severity: | Affects Many People | CC: | feld, olgeni, skozlov | ||||||||||
| Priority: | --- | Flags: | rakuco:
maintainer-feedback+
|
||||||||||
| Version: | Latest | ||||||||||||
| Hardware: | Any | ||||||||||||
| OS: | Any | ||||||||||||
| Attachments: |
|
||||||||||||
Hello, Thanks a lot for the feedback, glad to hear that the port helps you. I can come up with two major problems with letting Kibana write to it's own source files 1) It will brake the deinstallation of the package Because the pkg-plist won't match, maybe there's a possibility to work around that somehow, but I don't have an immediate answer 2) It can make be a security concern because an attacker which can gain control over the node process can then modify the sources to fit his needs Still, there's a part of the functionality which can't be used because of strict permissions to the www/kibana* directory, I need to think about that for a while. I've seen olgeni@ added himself to the CC list, maybe you have any thoughts on how to handle that, Jimmy? (In reply to Sergey Kozlov from comment #1) Just to be clear, I certainly wasn't proposing that there should be a port that modifies its files every once in a while. Totally agree with both points, which is why I said I don't know whether this should be classified as a bug relevant to the port. Created attachment 167206 [details]
Patch to remove optimize folder
(In reply to Athanasios Douitsis from comment #2) I've uploaded a patch which can fix the problem. It basically deletes the kibana4X/optimize folder contents from the package and lets Kibana recreate it on startup. There're two drawbacks I can see with this patch now: 1) 'optimize' folder is writable for node.js process now. Don't think that can be avoided with present architecture of Kibana anyway 2) The first start of Kibana is much slower, on my VM it takes around 1 minute while the process recreates the contents of the optimize folder. It only happens once after the installation or settings change though. Athanasios, could you please test the patch on your setup? Does it fix your problem and, which is very important, does it cleanly deinstall after usage with modified settings in kibana.yml? Thanks, Sergey (In reply to Sergey Kozlov from comment #4) Hello, Removed the existing kibana43 pkg, svn checked out your 3 ports, patched and then made install kibana44. Sure enough, with my custom basePathr, it worked after optimizing for a couple of minutes. Unfortunately kibana44 now requires a newer elasticsearch version not yet available as pkg, but it does come up, so I see no problem really. Pkg remove didn't emit any problems either. Hope this helps. Many thanks from me for your work. Created attachment 167272 [details] The Patch (In reply to Athanasios Douitsis from comment #5) Thank you very much for putting your effort and time into this. I've added the final patch which is ready to be committed. Changes: - Allows user to customize some Kibana's settings without interfering with the deinstallation process of the package (bug #207209) Drawbacks: - Kibana takes couple of minutes to start for the first time after package installation or settings' change (There's a warning in the log about that) - ${WWWDIR}/optimize folder is now writable, weakening the security. Although, given the architecture of Kibana it's inevitable Created attachment 167273 [details]
Portlint log
Created attachment 167274 [details]
The Patch
Uploaded the wrong file as the patch, fixing
A commit references this bug: Author: feld Date: Mon Mar 14 16:10:27 UTC 2016 New revision: 411098 URL: https://svnweb.freebsd.org/changeset/ports/411098 Log: textproc/kibana42, kibana43, kibana44: Fix ability to customize settings Changes: - Allows user to customize some Kibana's settings without interfering with the deinstallation process of the package (bug #207209) Drawbacks: - Kibana takes couple of minutes to start for the first time after package installation or settings' change (There's a warning in the log about that) - ${WWWDIR}/optimize folder is now writable, weakening the security. Although, given the architecture of Kibana it's inevitable PR: 207209 Changes: head/textproc/kibana42/Makefile head/textproc/kibana42/pkg-plist head/textproc/kibana43/Makefile head/textproc/kibana43/pkg-plist head/textproc/kibana44/Makefile head/textproc/kibana44/pkg-plist Hello, Thanks for this patch! The change to wipe the optimize folder is unfortunate, but required because the files within will have the wrong permissions. Perhaps in the future it can just be removed. |
Hello, May I extend my deepest thanks for making this port available and keeping it updated. I don't know whether this should be classified as a bug relevant to the port, but here goes. Using textproc/kibana43-4.3.1. I've noticed that all the files under /usr/local/www/kibana43/ incl. the directory itself are root:wheel by default. When trying to use the server.basePath conf directive in kibana.yml (e.g. server.basePath: /kibana4), kibana4 will try to modify files under the /usr/local/www/kibana43/optimize/bundles/ path and possibly other paths. Since kibana4 by default runs as www:www, this is not possible and kibana will not be able to start with this error: {"type":"log","@timestamp":"2016-02-14T13:15:04+00:00","tags":["fatal"],"pid":52116,"level":"fatal","message":"EACCES, open '/usr/local/www/kibana43/optimize/bundles/kibana.entry.js'","error":{"message":"EACCES, open '/usr/local/www/kibana43/optimize/bundles/kibana.entry.js'","name":"Error","stack":"Error: EACCES, open '/usr/local/www/kibana43/optimize/bundles/kibana.entry.js'\n at Error (native)","code":"EACCES"}} I was able to workaround by doing chown -R www:www /usr/local/www/kibana43. It may be possible to narrow down the directory even further. Furthermore, permissions for the contents of /usr/local/www/kibana43 are -w, so a similar error will be logged even if the permissions are correct. So chmod -R u+x /usr/local/www/kibana43 did the trick. Again, maybe this could be made even narrower.