Bug 207209 - textproc/kibana4 /usr/local/www/kibana43 ownership and permissions
Summary: textproc/kibana4 /usr/local/www/kibana43 ownership and permissions
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-15 11:57 UTC by Athanasios Douitsis
Modified: 2016-03-14 16:12 UTC (History)
3 users (show)

See Also:
rakuco: maintainer-feedback+


Attachments
Patch to remove optimize folder (8.36 KB, patch)
2016-02-19 22:29 UTC, Serhii (Sergey) Kozlov
no flags Details | Diff
The Patch (1.29 KB, patch)
2016-02-21 22:58 UTC, Serhii (Sergey) Kozlov
skozlov: maintainer-approval+
Details | Diff
Portlint log (1.29 KB, text/plain)
2016-02-21 23:00 UTC, Serhii (Sergey) Kozlov
no flags Details
The Patch (9.26 KB, patch)
2016-02-21 23:03 UTC, Serhii (Sergey) Kozlov
rakuco: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Athanasios Douitsis 2016-02-15 11:57:23 UTC
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.
Comment 1 Serhii (Sergey) Kozlov freebsd_committer 2016-02-17 22:51:26 UTC
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?
Comment 2 Athanasios Douitsis 2016-02-18 07:30:54 UTC
(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.
Comment 3 Serhii (Sergey) Kozlov freebsd_committer 2016-02-19 22:29:47 UTC
Created attachment 167206 [details]
Patch to remove optimize folder
Comment 4 Serhii (Sergey) Kozlov freebsd_committer 2016-02-19 22:38:52 UTC
(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
Comment 5 Athanasios Douitsis 2016-02-20 00:45:12 UTC
(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.
Comment 6 Serhii (Sergey) Kozlov freebsd_committer 2016-02-21 22:58:58 UTC
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
Comment 7 Serhii (Sergey) Kozlov freebsd_committer 2016-02-21 23:00:38 UTC
Created attachment 167273 [details]
Portlint log
Comment 8 Serhii (Sergey) Kozlov freebsd_committer 2016-02-21 23:03:24 UTC
Created attachment 167274 [details]
The Patch

Uploaded the wrong file as the patch, fixing
Comment 9 commit-hook freebsd_committer 2016-03-14 16:10:57 UTC
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
Comment 10 Mark Felder freebsd_committer 2016-03-14 16:12:17 UTC
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.