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 · 11 comments
Closed
Assignees
Labels
:Delivery/Packaging RPM and deb packaging, tar and zip archives, shell and batch scripts >enhancement Team:Delivery Meta label for Delivery team v2.0.0

Comments

@tlrx
Copy link
Member

tlrx 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.

@tlrx tlrx added v2.0.0-beta1 :Delivery/Packaging RPM and deb packaging, tar and zip archives, shell and batch scripts labels May 6, 2015
@tlrx tlrx self-assigned this May 6, 2015
@rjernst
Copy link
Member

rjernst 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
Copy link
Contributor

rmuir 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
Copy link
Member

nik9000 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
Copy link
Member Author

tlrx 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
Copy link
Member

rjernst commented May 6, 2015

Ok thanks. LGTM

@ael-code
Copy link

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
Copy link
Member Author

tlrx 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 the help wanted adoptme label Oct 6, 2015
@javanna javanna self-assigned this Oct 7, 2015
@javanna javanna removed the help wanted adoptme label Oct 8, 2015
javanna added a commit to javanna/elasticsearch that referenced this issue Oct 8, 2015
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
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
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
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
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
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
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
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
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
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
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
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
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
Copy link
Member

javanna commented Oct 14, 2015

Implemented via #14017 , #14048 and #14088

@javanna javanna closed this as completed Oct 14, 2015
@carnalim
Copy link

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
Copy link
Contributor

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

@hscspring
Copy link

i think in docker root is ok.

@mark-vieira mark-vieira added the Team:Delivery Meta label for Delivery team label Nov 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Delivery/Packaging RPM and deb packaging, tar and zip archives, shell and batch scripts >enhancement Team:Delivery Meta label for Delivery team v2.0.0
Projects
None yet
Development

No branches or pull requests

10 participants