-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
_FILE variable permission check does not follow symlinks #49653
Labels
:Delivery/Packaging
RPM and deb packaging, tar and zip archives, shell and batch scripts
Team:Delivery
Meta label for Delivery team
v7.7.0
v8.0.0-alpha1
Comments
pebrc
changed the title
_FILE variable support causes issues on k8s
_FILE variable permission check does not follow symlinks
Nov 27, 2019
This was referenced Nov 27, 2019
pugnascotia
added
the
:Delivery/Packaging
RPM and deb packaging, tar and zip archives, shell and batch scripts
label
Nov 27, 2019
Pinging @elastic/es-core-infra (:Core/Infra/Packaging) |
pugnascotia
added a commit
to pugnascotia/elasticsearch
that referenced
this issue
Jan 13, 2020
Closes elastic#49653. When using _FILE environment variables to supply values to Elasticsearch, following symlinks when checking that file permissions are secure.
pugnascotia
added a commit
that referenced
this issue
Jan 16, 2020
Closes #49653. When using _FILE environment variables to supply values to Elasticsearch, following symlinks when checking that file permissions are secure.
pugnascotia
added a commit
to pugnascotia/elasticsearch
that referenced
this issue
Jan 16, 2020
Closes elastic#49653. When using _FILE environment variables to supply values to Elasticsearch, following symlinks when checking that file permissions are secure.
pugnascotia
added a commit
to pugnascotia/elasticsearch
that referenced
this issue
Jan 16, 2020
Closes elastic#49653. When using _FILE environment variables to supply values to Elasticsearch, following symlinks when checking that file permissions are secure.
pugnascotia
added a commit
that referenced
this issue
Jan 18, 2020
pugnascotia
added a commit
that referenced
this issue
Jan 18, 2020
SivagurunathanV
pushed a commit
to SivagurunathanV/elasticsearch
that referenced
this issue
Jan 23, 2020
Closes elastic#49653. When using _FILE environment variables to supply values to Elasticsearch, following symlinks when checking that file permissions are secure.
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
Team:Delivery
Meta label for Delivery team
v7.7.0
v8.0.0-alpha1
Elasticsearch version (
bin/elasticsearch --version
): 7.6.0-SNAPSHOT / 8.0.0-SNAPSHOTPlugins installed: []
JVM version (
java -version
): official Docker imageOS version (
uname -a
if on a Unix-like system): official Docker imageDescription of the problem including expected versus actual behavior:
#49182 introduces support for environment variables ending in
_FILE
to point to a file that will be read to create the value of an environment variable of the name minus the_FILE
suffix. The startup script imposes strict permission checks on these files and requires them to have either0400
or0600
permissions.On Kubernetes these sensitive files are typically mounted as so called
Secrets
into the docker container. That introduces an additional level of indirection with a symlink that has0777
file permissions and therefore fails the checks in the Elasticsearch startup script.The expected behaviour would be to check the permissions on the effective file after following symlinks instead.
Example shell session on an ECK managed Elasticsearch container to illustrate the problem:
where
/mnt/elastic-internal/proble-user
is a volume mount of a k8s volume with the following definition:Note:
defaultMode
are the file permissions base 10 ie. 384 == 0600Steps to reproduce:
Run Elasticsearch 7.6.0-SNAPSHOT on k8s with an environment variable ending in
_FILE
and a corresponding file mounted into the pod. Probably the easiest way to achieve that is torun Elasticsearch on ECK 1.0.0-beta1 with this manifest:
The text was updated successfully, but these errors were encountered: