Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RPM/DEB packages: change permissions/ownership of config and bin plugins dirs #11016

Closed
tlrx opened this issue May 6, 2015 · 10 comments

Comments

Projects
None yet
8 participants
@tlrx
Copy link
Member

commented May 6, 2015

When installing elasticsearch with a RPM or DEB package, the configuration directory /etc/elasticsearch should be owned by user root and group elasticsearch with 750 permissions (root has full access, read/list access for users of elasticsearch group and nothing for others users)

When installing a plugin that contains configuration files like /etc/elasticsearch/awesome-plugin/, the plugin directory should be owned by user root and group elasticsearch with 750 permissions.

When installing a plugin that contains bin/ files like /usr/share/elasticsearch/bin/awesome-plugin/, the plugin directory and all its files should be owned by user root and group elasticsearch with 750 permissions (root has read/write/execute access, read/execute access for users of elasticsearch group and nothing for others users).

We also need to test how RPM/DEB packages handle permissions/ownership changes when upgrading a package.

@rjernst

This comment has been minimized.

Copy link
Member

commented May 6, 2015

@tlrx Why is root ownership needed? Is this to make sure the ES process (which is run as a user in the elasticsearch group) cannot modify these files? It just seems weird that someone trying to configure e.g. elasticsearch.yml would need to run as root/sudo? But maybe it is just weird to me. :)

@rmuir

This comment has been minimized.

Copy link
Contributor

commented May 6, 2015

It just seems weird that someone trying to configure e.g. elasticsearch.yml would need to run as root/sudo?

I don't think its wierd to require root/sudo to change configuration files in /etc at all.

@nik9000

This comment has been minimized.

Copy link
Contributor

commented May 6, 2015

I don't think its wierd to require root/sudo to change configuration files in /etc at all.

+1

/etc/elasticsearch/* is owned by root with 444. World readable because why not and not world writable because its written by puppet.

@tlrx

This comment has been minimized.

Copy link
Member Author

commented May 6, 2015

@rjernst yes, that's the idea. There was a debate about this but I think it makes sense, specially when elasticsearch is installed with a rpm/deb package (where rpm/dpkg commands often require to be executed as root)

@rjernst

This comment has been minimized.

Copy link
Member

commented May 6, 2015

Ok thanks. LGTM

@ael-code

This comment has been minimized.

Copy link

commented May 13, 2015

I've installed Elasticsearch 1.5.2 on debian jessy through official elasticsearch repo.
First time I've launched systemctl start elasticsearch the bootstrap failed because of denied permission to create /usr/share/elasticsearch/data folder.

Error log:

May 13 10:02:59 debian8VM elasticsearch[792]: - ElasticsearchIllegalStateException[Failed to created node environment]
May 13 10:02:59 debian8VM elasticsearch[792]: AccessDeniedException[/usr/share/elasticsearch/data]
May 13 10:02:59 debian8VM elasticsearch[792]: org.elasticsearch.ElasticsearchIllegalStateException: Failed to created node environment
May 13 10:02:59 debian8VM elasticsearch[792]: at org.elasticsearch.node.internal.InternalNode.<init>(InternalNode.java:162)
May 13 10:02:59 debian8VM elasticsearch[792]: at org.elasticsearch.node.NodeBuilder.build(NodeBuilder.java:159)
May 13 10:02:59 debian8VM elasticsearch[792]: at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:70)
May 13 10:02:59 debian8VM elasticsearch[792]: at org.elasticsearch.bootstrap.Bootstrap.main(Bootstrap.java:213)
May 13 10:02:59 debian8VM elasticsearch[792]: at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:32)
May 13 10:02:59 debian8VM elasticsearch[792]: Caused by: java.nio.file.AccessDeniedException: /usr/share/elasticsearch/data

folder permissions just after package installation:

ls -lah /usr/share/elasticsearch
drwxr-xr-x   5 root          root          4.0K May 13 06:04 .
drwxr-xr-x 116 root          root          4.0K May 13 06:04 ..
drwxr-xr-x   2 root          root          4.0K May 13 06:04 bin
drwxr-xr-x   3 root          root          4.0K May 13 06:04 lib
-rw-r--r--   1 root          root           150 Apr 27 04:22 NOTICE.txt
drwxr-xr-x   2 elasticsearch elasticsearch 4.0K May 13 06:04 plugins
-rw-r--r--   1 root          root          8.3K Apr 27 04:22 README.textile

to solve the issue I've manually created the fodler:
drwxr-xr-x 3 elasticsearch elasticsearch 4.0K May 13 10:14 data

Do I need to open new issue or it is related to this one?

@tlrx

This comment has been minimized.

Copy link
Member Author

commented May 13, 2015

@ael-code thanks for reporting. I think you hit the same issue as #10938 which will be fixed with #10725.

@clintongormley clintongormley added v2.0.0 and removed v2.0.0-beta1 labels Aug 13, 2015

@javanna javanna self-assigned this Oct 7, 2015

@javanna javanna removed the help wanted label Oct 8, 2015

javanna added a commit to javanna/elasticsearch that referenced this issue Oct 8, 2015

Packaging: change permissions/ownership of config dir
When generating the rpm and dep package we now set proper group (elasticsearch) and permissions (750) to the conf dir (default /etc/elasticsearch). Same for the scripts subdirectory.

Expanded the assert_file bash function to also optionally check the group of files, so we can actually test that the group was set correctly.

Relates to elastic#11016
Closes elastic#14017

javanna added a commit that referenced this issue Oct 8, 2015

Packaging: change permissions/ownership of config dir
When generating the rpm and dep package we now set proper group (elasticsearch) and permissions (750) to the conf dir (default /etc/elasticsearch). Same for the scripts subdirectory.

Expanded the assert_file bash function to also optionally check the group of files, so we can actually test that the group was set correctly.

Relates to #11016
Closes #14017

javanna added a commit that referenced this issue Oct 8, 2015

Packaging: change permissions/ownership of config dir
When generating the rpm and dep package we now set proper group (elasticsearch) and permissions (750) to the conf dir (default /etc/elasticsearch). Same for the scripts subdirectory.

Expanded the assert_file bash function to also optionally check the group of files, so we can actually test that the group was set correctly.

Relates to #11016
Closes #14017

javanna added a commit that referenced this issue Oct 8, 2015

Packaging: change permissions/ownership of config dir
When generating the rpm and dep package we now set proper group (elasticsearch) and permissions (750) to the conf dir (default /etc/elasticsearch). Same for the scripts subdirectory.

Expanded the assert_file bash function to also optionally check the group of files, so we can actually test that the group was set correctly.

Relates to #11016
Closes #14017

javanna added a commit that referenced this issue Oct 8, 2015

Packaging: change permissions/ownership of config dir
When generating the rpm and dep package we now set proper group (elasticsearch) and permissions (750) to the conf dir (default /etc/elasticsearch). Same for the scripts subdirectory.

Expanded the assert_file bash function to also optionally check the group of files, so we can actually test that the group was set correctly.

Relates to #11016
Closes #14017

javanna added a commit to javanna/elasticsearch that referenced this issue Oct 13, 2015

Plugins: plugin script to set proper plugin config dir attributes
Depending on how elasticsearch is installed, we have two scenarios to take into account that relate to user, group and permissions assigned to the config directory:

1) deb/rpm package: /etc/elasticsearch is root:elasticsearch 750 and the plugin script is run from root user
2) tar/zip archive: es config dir is most likely elasticsearch:elasticsearch and the plugin script is most likely run from elasticsearch user

When the plugin script copies over the plugin config dir within the es config dir, it should take care of setting the proper user, group and permissions, which vary depending on how elasticsearch was installed in the first place. Should be root:elasticsearch 750 if installed from a package, or elasticsearch:elasticsearch if installed from an archive.

This commit makes sure that the plugin script looks at user, group and permissions of the config dir and copies them over to the plugin config subdirectory, whatever they are, so that they get properly setup depending on how elasticsearch was installed in the first place. We also make sure that execute permissions are left untouched for files.

Relates to elastic#11016
Closes elastic#14048

javanna added a commit that referenced this issue Oct 13, 2015

Plugins: plugin script to set proper plugin config dir attributes
Depending on how elasticsearch is installed, we have two scenarios to take into account that relate to user, group and permissions assigned to the config directory:

1) deb/rpm package: /etc/elasticsearch is root:elasticsearch 750 and the plugin script is run from root user
2) tar/zip archive: es config dir is most likely elasticsearch:elasticsearch and the plugin script is most likely run from elasticsearch user

When the plugin script copies over the plugin config dir within the es config dir, it should take care of setting the proper user, group and permissions, which vary depending on how elasticsearch was installed in the first place. Should be root:elasticsearch 750 if installed from a package, or elasticsearch:elasticsearch if installed from an archive.

This commit makes sure that the plugin script looks at user, group and permissions of the config dir and copies them over to the plugin config subdirectory, whatever they are, so that they get properly setup depending on how elasticsearch was installed in the first place. We also make sure that execute permissions are left untouched for files.

Relates to #11016
Closes #14048

javanna added a commit that referenced this issue Oct 13, 2015

Plugins: plugin script to set proper plugin config dir attributes
Depending on how elasticsearch is installed, we have two scenarios to take into account that relate to user, group and permissions assigned to the config directory:

1) deb/rpm package: /etc/elasticsearch is root:elasticsearch 750 and the plugin script is run from root user
2) tar/zip archive: es config dir is most likely elasticsearch:elasticsearch and the plugin script is most likely run from elasticsearch user

When the plugin script copies over the plugin config dir within the es config dir, it should take care of setting the proper user, group and permissions, which vary depending on how elasticsearch was installed in the first place. Should be root:elasticsearch 750 if installed from a package, or elasticsearch:elasticsearch if installed from an archive.

This commit makes sure that the plugin script looks at user, group and permissions of the config dir and copies them over to the plugin config subdirectory, whatever they are, so that they get properly setup depending on how elasticsearch was installed in the first place. We also make sure that execute permissions are left untouched for files.

Relates to #11016
Closes #14048

javanna added a commit that referenced this issue Oct 13, 2015

Plugins: plugin script to set proper plugin config dir attributes
Depending on how elasticsearch is installed, we have two scenarios to take into account that relate to user, group and permissions assigned to the config directory:

1) deb/rpm package: /etc/elasticsearch is root:elasticsearch 750 and the plugin script is run from root user
2) tar/zip archive: es config dir is most likely elasticsearch:elasticsearch and the plugin script is most likely run from elasticsearch user

When the plugin script copies over the plugin config dir within the es config dir, it should take care of setting the proper user, group and permissions, which vary depending on how elasticsearch was installed in the first place. Should be root:elasticsearch 750 if installed from a package, or elasticsearch:elasticsearch if installed from an archive.

This commit makes sure that the plugin script looks at user, group and permissions of the config dir and copies them over to the plugin config subdirectory, whatever they are, so that they get properly setup depending on how elasticsearch was installed in the first place. We also make sure that execute permissions are left untouched for files.

Relates to #11016
Closes #14048

javanna added a commit to javanna/elasticsearch that referenced this issue Oct 14, 2015

Plugins: plugin script to set proper plugin bin dir attributes
This commit makes sure that the plugin script looks at user, group and permissions of the elasticsearch bin dir and copies them over to the plugin bin subdirectory, whatever they are, so that they get properly setup depending on how elasticsearch was installed. We also make sure that execute permissions are added for files (we already did this before).

Relates to elastic#11016
Closes elastic#14088

javanna added a commit that referenced this issue Oct 14, 2015

Plugins: plugin script to set proper plugin bin dir attributes
This commit makes sure that the plugin script looks at user, group and permissions of the elasticsearch bin dir and copies them over to the plugin bin subdirectory, whatever they are, so that they get properly setup depending on how elasticsearch was installed. We also make sure that execute permissions are added for files (we already did this before).

Relates to #11016
Closes #14088

javanna added a commit that referenced this issue Oct 14, 2015

Plugins: plugin script to set proper plugin bin dir attributes
This commit makes sure that the plugin script looks at user, group and permissions of the elasticsearch bin dir and copies them over to the plugin bin subdirectory, whatever they are, so that they get properly setup depending on how elasticsearch was installed. We also make sure that execute permissions are added for files (we already did this before).

Relates to #11016
Closes #14088

javanna added a commit that referenced this issue Oct 14, 2015

Plugins: plugin script to set proper plugin bin dir attributes
This commit makes sure that the plugin script looks at user, group and permissions of the elasticsearch bin dir and copies them over to the plugin bin subdirectory, whatever they are, so that they get properly setup depending on how elasticsearch was installed. We also make sure that execute permissions are added for files (we already did this before).

Relates to #11016
Closes #14088
@javanna

This comment has been minimized.

Copy link
Member

commented Oct 14, 2015

Implemented via #14017 , #14048 and #14088

@javanna javanna closed this Oct 14, 2015

@carnalim

This comment has been minimized.

Copy link

commented Dec 15, 2015

I dont think this issue is closed, on the latest build I just experienced this problem:

From the install: [root@ip-10-94-146-130 bin]# ./plugin install file:///home/jmblnvr/shield/license-2.1.0.zip
-> Installing from file:/home/jmblnvr/shield/license-2.1.0.zip...
Trying file:/home/jmblnvr/shield/license-2.1.0.zip ...
Downloading .DONE
Verifying file:/home/jmblnvr/shield/license-2.1.0.zip checksums if available ...
NOTE: Unable to verify checksum for downloaded plugin (unable to find .sha1 or .md5 file to verify)
Installed license into /usr/share/elasticsearch/plugins/license
[root@ip-10-94-146-130 bin]# service elasticsearch restart
Stopping elasticsearch:                                    [FAILED]
Starting elasticsearch: Exception in thread "main" java.lang.IllegalStateException: Unable to initialize plugins
Likely root cause: java.nio.file.AccessDeniedException: /usr/share/elasticsearch/plugins/license/plugin-descriptor.properties
    at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
    at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
    at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
    at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
    at java.nio.file.Files.newByteChannel(Files.java:361)
    at java.nio.file.Files.newByteChannel(Files.java:407)
    at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
    at java.nio.file.Files.newInputStream(Files.java:152)
    at org.elasticsearch.plugins.PluginInfo.readFromProperties(PluginInfo.java:86)
    at org.elasticsearch.plugins.PluginsService.getPluginBundles(PluginsService.java:302)
    at org.elasticsearch.plugins.PluginsService.<init>(PluginsService.java:108)
    at org.elasticsearch.node.Node.<init>(Node.java:148)
    at org.elasticsearch.node.Node.<init>(Node.java:129)
    at org.elasticsearch.node.NodeBuilder.build(NodeBuilder.java:145)
    at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:178)
    at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:285)
    at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:35)
Refer to the log for complete error details.
                                                           [FAILED]

From Var Log:

[root@ip-10-94-146-130 elasticsearch]# cat elasticsearch.log
[2015-12-15 11:44:24,525][INFO ][node                     ] [Valtorr] stopping ...
[2015-12-15 11:44:24,639][INFO ][node                     ] [Valtorr] stopped
[2015-12-15 11:44:24,641][INFO ][node                     ] [Valtorr] closing ...
[2015-12-15 11:44:24,647][INFO ][node                     ] [Valtorr] closed
[2015-12-15 11:44:26,097][WARN ][bootstrap                ] unable to install syscall filter: seccomp unavailable: CONFIG_SECCOMP not compiled into kernel, CONFIG_SECCOMP and CONFIG_SECCOMP_FILTER are needed
[2015-12-15 11:44:26,314][INFO ][node                     ] [Agon] version[2.1.0], pid[21703], build[72cd1f1/2015-11-18T22:40:03Z]
[2015-12-15 11:44:26,314][INFO ][node                     ] [Agon] initializing ...
[2015-12-15 11:44:26,318][ERROR][bootstrap                ] Exception
java.lang.IllegalStateException: Unable to initialize plugins
    at org.elasticsearch.plugins.PluginsService.<init>(PluginsService.java:111)
    at org.elasticsearch.node.Node.<init>(Node.java:148)
    at org.elasticsearch.node.Node.<init>(Node.java:129)
    at org.elasticsearch.node.NodeBuilder.build(NodeBuilder.java:145)
    at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:178)
    at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:285)
    at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:35)
Caused by: java.nio.file.AccessDeniedException: /usr/share/elasticsearch/plugins/license/plugin-descriptor.properties
    at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
    at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
    at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
    at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
    at java.nio.file.Files.newByteChannel(Files.java:361)
    at java.nio.file.Files.newByteChannel(Files.java:407)
    at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
    at java.nio.file.Files.newInputStream(Files.java:152)
    at org.elasticsearch.plugins.PluginInfo.readFromProperties(PluginInfo.java:86)
    at org.elasticsearch.plugins.PluginsService.getPluginBundles(PluginsService.java:302)
    at org.elasticsearch.plugins.PluginsService.<init>(PluginsService.java:108)
    ... 6 more

Fixed with:
chown -R root:elasticsearch /usr/share/elasticsearch

@clintongormley

This comment has been minimized.

Copy link
Member

commented Dec 16, 2015

I've just tried this on a fresh install and it works correctly. I wonder if you had an existing directory with incorrect ownership?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.