-
Notifications
You must be signed in to change notification settings - Fork 25k
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
Comments
@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. :) |
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. |
@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) |
Ok thanks. LGTM |
I've installed Elasticsearch 1.5.2 on debian jessy through official elasticsearch repo. Error log:
folder permissions just after package installation:
to solve the issue I've manually created the fodler: Do I need to open new issue or it is related to this one? |
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
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
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
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
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
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
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
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
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
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
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
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
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
I dont think this issue is closed, on the latest build I just experienced this problem:
From Var Log:
Fixed with: |
I've just tried this on a fresh install and it works correctly. I wonder if you had an existing directory with incorrect ownership? |
i think in docker root is ok. |
When installing elasticsearch with a RPM or DEB package, the configuration directory
/etc/elasticsearch
should be owned by userroot
and groupelasticsearch
with750
permissions (root
has full access, read/list access for users ofelasticsearch
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 userroot
and groupelasticsearch
with750
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 userroot
and groupelasticsearch
with750
permissions (root
has read/write/execute access, read/execute access for users ofelasticsearch
group and nothing for others users).We also need to test how RPM/DEB packages handle permissions/ownership changes when upgrading a package.
The text was updated successfully, but these errors were encountered: