Archivos identificados en la descripción:

• lib / ansible / cli / config.py

Si estos archivos son inexactos, actualice la sección component name de la descripción o use el comando !component bot.

haga clic aquí para obtener ayuda con el bot

Archivos identificados en la descripción:

• lib / ansible / config / manager.py

Si estos archivos son inexactos, actualice la sección component name de la descripción o use el comando !component bot.

haga clic aquí para obtener ayuda con el bot

Detectar que el sistema es WSL aún dejaría una vulnerabilidad. Tendríamos que detectar que el archivo no se puede escribir en todo el mundo o en un directorio que se puede escribir en todo el mundo a pesar de que los permisos dicen que sí.

Tampoco admitimos Ansible en hosts de Windows, por lo que no podemos garantizar que se cree una solución para esto.

Entiendo absolutamente la necesidad de seguridad, pero al menos debería haber una opción para desactivarla. Tal vez algo que tenga que estar en el /etc/ansible/ansible.cfg específicamente o algo similar que haga que sea más difícil encenderlo.

Hay otros casos de uso en los que no sería solo un montaje NTFS de Windows 10 en WSL que esto ocurriría. Si tiene un montaje NTFS o un montaje de recurso compartido de archivos de Azure en un cuadro de compilación de Linux bloqueado, el montaje sería 777, pero no significa que no sea seguro confiar en los archivos de esa ubicación.

OpenSSH no le impide habilitar el inicio de sesión con contraseña root , pero sí le dice que es una mala idea. La mayoría de las pautas de seguridad se relacionan con el propósito y el contexto que lo rodea.

¿Quizás podría permitir que las personas incluyan directorios en la lista blanca de esta verificación mediante una variable de entorno? ¿Algo como ANSIBLE_TRUSTED_CONFIGPATHS o algo así? Si la configuración está dentro de una ruta en esa variable, ¿omitir la verificación de permisos?

No soy tan bueno en Python, pero ¿tal vez algo como esto?

diff --git a/lib/ansible/config/manager.py b/lib/ansible/config/manager.py
index 48cf2cba3a..b356c84b9e 100644
--- a/lib/ansible/config/manager.py
+++ b/lib/ansible/config/manager.py
@@ -146,6 +146,10 @@ def find_ini_config_file(warnings=None):
    ''' Load INI Config File order(first found is used): ENV, CWD, HOME, /etc/ansible '''
    # FIXME: eventually deprecate ini configs

+    trusted_paths = os.getenv("ANSIBLE_TRUSTED_CONFIGPATHS",None)
+    if isinstance(trusted_paths, string_types):
+        trusted_paths=list(filter(None,trusted_paths.split(':')))
+
    path0 = os.getenv("ANSIBLE_CONFIG", None)
    if path0 is not None:
        path0 = unfrackpath(path0, follow=False)
@@ -154,7 +158,9 @@ def find_ini_config_file(warnings=None):
    try:
        path1 = os.getcwd()
        perms1 = os.stat(path1)
-        if perms1.st_mode & stat.S_IWOTH:
+        if trusted_paths and [i for i in trusted_paths if path1.startswith(i)]:
+            path1 += "/ansible.cfg"
+        elif perms1.st_mode & stat.S_IWOTH:
            if warnings is not None:
                warnings.add("Ansible is in a world writable directory (%s), ignoring it as an ansible.cfg source." % to_text(path1))
            path1 = None

Entonces, ¿puedo configurar export ANSIBLE_TRUSTED_CONFIGPATHS=/mnt/c/Users/ en mi perfil de shell?

Puede configurar la variable ANSIBLE_CONFIG para que apunte a su mundo de escritura ansible.cfg y actualmente funciona.

Sí, es solo el directorio de trabajo actual en el que estamos haciendo esta prueba.
Evita sorpresas como explorar su árbol de archivos y luego ejecutar
ansible en / tmp y recogiendo un ansible.cfg malicioso

El jueves, 5 de julio de 2018, 11:23 p.m. Ramin Baradari [email protected]
escribió:

Puede configurar la variable ANSIBLE_CONFIG para que apunte a su mundo escribible
ansible.cfg y actualmente funciona.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ansible/ansible/issues/42388#issuecomment-402938591 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAMxWr8Z2LerEPWWmwZu1BR5RT9qgdnTks5uDwJ5gaJpZM4VEmwB
.

Estoy usando vagrant en Windows para ejecutar libros de jugadas ansible.

Sigue fallando incluso después de establecer el valor ansible_config.

[ root @ controller ] # echo $ ANSIBLE_CONFIG
/ inicio / vagabundo / proyectos / DevOps-Proyectos /

[ root @ controller mapr-ansible-paysafe] # ls -lh ansible.cfg
-rwxrwxrwx. 1 vagabundo vagabundo 73 9 de julio 07:43 ansible.cfg

[ root @ controller ] # ansible -m ping all -i environment / XXXX / cluster.ini -v
[ADVERTENCIA] Ansible está en un directorio de escritura mundial (/ home / vagrant / projects / DevOps-Projects), ignorándolo como fuente ansible.cfg .
No se encontró ningún archivo de configuración; usando valores predeterminados

Solución temporal
Install Only ansible 2.6.0

La var ANSIBLE_CONFIG env debe apuntar a un archivo, no a un directorio.

Me encontré con el mismo problema y no quiero un cfg global para todos mis proyectos, necesito una configuración relativa al proyecto. Entonces, ¿cómo puedo solucionar esto por mí?

Me encontré con el mismo problema y no quiero un cfg global para todos mis proyectos, necesito una configuración relativa al proyecto. Entonces, ¿cómo puedo solucionar esto por mí?

pip install ansible==2.6.0 hasta que los desarrolladores decidan cómo quieren manejar esto.

También hay problemas en la carpeta compartida de Vagrant, en este caso es el modo solo 0777 para carpetas y no se puede cambiar.
Por favor, agregue verificar que la carpeta CWD == carpeta que contiene el archivo del libro de jugadas, y luego no verifique si se puede escribir en el mundo. ¿O tal vez intente encontrar ansible.cfg en la misma carpeta que el archivo del libro de jugadas? Sería útil para usuarios vagabundos en Windows.

Creo que encontré una solución para 2.6.1 y así sucesivamente ...

Cree este archivo en su wsl: /etc/wsl.conf

Contenido:

[automount]
enabled = true
mountFsTab = false
root = /mnt/
options = "metadata,umask=22,fmask=11"

[network]
generateHosts = true
generateResolvConf = true

Después de eso, todo / mnt / c / foo tendrá diferentes permisos de carpeta (ya no 777) y podrá usar chmod.
Requiere que tenga la última WSL que yo sepa.
wsl.conf docs

De acuerdo, el comentario en https://github.com/ansible/ansible/issues/42388#issuecomment -403926971 es el equivalente al consejo que le diríamos a las personas que montan un sistema de archivos ntfs o vfat en Unix, así que creo que esa es la solución correcta aquí.

Para las personas que usan ANSIBLE_CONFIG (correctamente ... como señala agaffney, debe apuntar a un archivo, no a un directorio), verifique si el archivo de configuración realmente se está ignorando o si solo está escupiendo una advertencia adicional.

Al mirar el código, creo que el archivo de configuración se lee cuando ANSIBLE_CONFIG se usa correctamente. Si ese también es el directorio de trabajo actual, entonces se escupe el mensaje de advertencia además de la configuración que se está usando porque está listada en ANSIBLE_CONFIG. Si ese es realmente el síntoma que se está viendo, debería ser fácil solucionarlo para que solo emita la advertencia si la única razón para usar la configuración es porque está en el directorio de trabajo actual.

`` `diff --git a / lib / ansible / config / manager.py b / lib / ansible / config / manager.py
índice c308c3810d..36641d9e01 100644
--- a / lib / ansible / config / manager.py
+++ b / lib / ansible / config / manager.py
@@ -150,6 +150,8 @@ def find_ini_config_file (advertencias = Ninguna):
'' 'Orden de carga del archivo de configuración INI (se usa el primero que se encuentra): ENV, CWD, HOME, / etc / ansible
# FIXME: eventualmente desaprobar las configuraciones ini

• warn_cwd_public = Falso
  +
  path0 = os.getenv ("ANSIBLE_CONFIG", Ninguno)
  si path0 no es None:
  path0 = unfrackpath (path0, follow = False)
  @@ -159,8 +161,7 @@ def find_ini_config_file (advertencias = Ninguna):
  ruta1 = os.getcwd ()
  perms1 = os.stat (ruta1)
  si perms1.st_mode & stat.S_IWOTH:
• si las advertencias no son Ninguna:
• warnings.add ("Ansible está en un directorio de escritura mundial (% s), ignorándolo como una fuente ansible.cfg."% to_text (ruta1))

• warn_cwd_public = Verdadero
  path1 = Ninguno
  más:
  ruta1 + = "/ansible.cfg"
  @@ -175,6 +176,8 @@ def find_ini_config_file (advertencias = Ninguna):
  más:
  ruta = Ninguno

• si warn_cwd_public y warnings no es None y path! = os.getcwd () + "/ansible.cfg":

• warnings.add ("Ansible está en un directorio de escritura mundial (% s), omitido de la lista de fuentes posibles ansible.cfg."% to_text (ruta1))
  camino de retorno
  algo como esto debería ser más preciso

Para mí, la mejor solución es cambiar el permiso en un sistema de archivos nfs montado en wsl con la opción Metadata activada. Para hacerlo, siga este procedimiento aquí: https://blogs.msdn.microsoft.com/commandline/2018/01/12/chmod-chown-wsl-improvements.

Básicamente, haga lo siguiente para su montaje ntfs para habilitar "chmod":

sudo umount /mnt/c
sudo mount -t drvfs C:/mnt/c -o metadata

Y luego haga el chmod en la carpeta y todo estará bien nuevamente. Una vez que los metadatos se adjuntan a la carpeta, permanecen allí. Debería ser wsl predeterminado para mi humilde opinión.

Solución para Vagrant, edite Vagrantfile y agregue mount_options :

config.vm.synced_folder "../my-folder", "/home/vagrant/my-folder",  mount_options: ["dmode=775"]

Este es un buen ejemplo de por qué ansible es un módulo de alto mantenimiento para construir su proyecto.

He preparado un proyecto vagrant + virtualbox + ansible hace 3 años. Desde entonces cada 5 meses se rompe ansible. Tengo que implementar soluciones para MANTENERLO FUNCIONANDO DE LA MISMA MANERA. Así que no puedo decirles a los (pocos) usuarios del sistema que "esto funciona", porque de vez en cuando simplemente se rompe. Esto funcionaba hace 3 semanas y no funciona ahora. Y no es un cambio de versión mayor, solo uno menor, por lo que los cambios importantes no son una opción.

(ver "touch" no implementado durante años, el módulo apt no tiene autoremove pero tiene advertencias implementadas de que no debería llamar a "apt" como comando, stat.md5 eliminado sin previo aviso, la ubicación de vault_password.txt no se permitió establecer en ansible. cfg (solicitud de función cerrada, luego implementada años después), etc.)

Debe utilizar soluciones alternativas cada pocas semanas para obtener el mismo resultado que antes.

Esperaba una gestión de proyectos más madura de Redhat y ansible 2.0, pero que esto sea una advertencia para los recién llegados, que ansible necesita mantenimiento.

¿Podría escribir esta advertencia en STDERR en lugar de STDOUT ?

[WARNING] Ansible is in a world writable directory...

Veo este mensaje cuando estoy descifrando un archivo de variables en STDOUT y voy a tener que hackear algún nodo de código especial para vigilar y eliminar esta línea.

Oh, ja, esto parece funcionar

export ANSIBLE_CONFIG=./ansible.cfg

Agregue eso en cualquier configuración vagrant / docker / wsl

Es genial conocer todas estas soluciones, pero creo que es una suposición ridícula y no tener una solución posible con los indicadores de libro de jugadas ansible en línea. Ahora me paso el día actualizando 40 trabajos de compilación con soluciones hacky, para romper los cambios que se introdujeron en un cambio de versión de parche. Y todas estas compilaciones se ejecutan en contenedores de corta duración a los que un solo usuario automatizado tiene acceso, por lo que este peligroso agujero de seguridad de escritura del mundo del que me estás protegiendo es una suposición completamente inválida.

Actualización rápida: no estamos ignorando esto, estamos viendo algunas ideas diferentes para preservar la corrección de seguridad de no leer la configuración de un cwd desprotegido. Créame, lo que se envió en respuesta a los recientes CVE en torno a esto fue un enfoque muy mesurado en comparación con algunas de las medidas draconianas que se están lanzando.

Dicho esto, estoy seguro de que podemos encontrar un refinamiento o una solución alternativa para respaldar estos casos de "escritura mundial, pero no realmente".

@thegreatjerboa ¿Puede ser más específico sobre su configuración? Tengo curiosidad por saber por qué está leyendo implícitamente ansible.cfg desde cwd en lugar de una ubicación fija (que debería funcionar bien con world-writable, si no, es un error).

@jefflill Estoy trabajando en una propuesta para solucionar el problema más general allí (que casi todas las advertencias y errores, así como la información detallada del tipo de depuración) van a stdout en lugar de stderr. desafortunadamente, sigo siendo atraído por otros problemas ...

@nitzmahone es el mismo directorio que el libro de jugadas. Tenemos un repositorio de git por libro de jugadas que se ejecuta al registrarse. Ansible.cfg y playbook son el nivel superior del repositorio, que también es el CWD cuando se ejecuta.

el directorio del libro de jugadas no se mira para ansible.cfg

export ANSIBLE_CONFIG=./ansible.cfg

NO está funcionando para mí, todavía obteniendo

 [WARNING] Ansible is in a world writable directory (/mnt/c/Users/soar/projectdir), ignoring it as an ansible.cfg source.

con ansible 2.6.2

Como pregunté antes ... ¿Realmente recoge el archivo de configuración a pesar de
imprimiendo esa advertencia?

La lógica era imprimir la advertencia incluso si se usó debido a
ANSIBLE_CONFIG.

43583 corrige la advertencia y debería fusionarse más tarde hoy para desarrollar (versiones posteriores a seguir)

Tener el mismo problema hoy después de la actualización. Estamos utilizando esto en producción, por lo que en este momento nuestros informes de clientes no funcionan. Proporcione una solución para esto.

Esto ahora se ha corregido en desarrollo a través de https://github.com/ansible/ansible/pull/43583 Backports para 2.6 y 2.5 están en los dos PR https://github.com/ansible/ansible/pull/43648 y https : //github.com/ansible/ansible/pull/43649 y el backport también se ha fusionado con stable-2.4 en caso de que haya otra versión 2.4.x.

¿Qué hay en la solución?

• Documentación que explica el riesgo de seguridad y señala la forma correcta de solucionarlo (montar el sistema de archivos para que el usuario y el grupo que necesita acceder a ansible.cfg puedan hacerlo en lugar de montar el mundo de directorios con permisos de escritura.
• Punteros a publicaciones de blog que explican cómo hacer esto tanto para vagabundos como para WSL (Vagrant no parece tener nada más oficial que las publicaciones de blog para explicar y la función WSL tiene documentación oficial y una publicación de blog que explica con más detalle cómo montar los sistemas de archivos).
• Documentación que explica que la configuración de ANSIBLE_CONFIG en el archivo de configuración que necesita se puede usar si realmente debe tenerlo en un directorio de escritura mundial como lo solicitan @AngellusMortis y @zoredache
• Una solución para la advertencia sobre omitir el directorio para que no parezca que el archivo de configuración se está omitiendo cuando se encuentra en un directorio de trabajo actual de escritura mundial Y se especifica en ANSIBLE_CONFIG.

Si aún experimenta este problema mientras prueba la rama devel, abra un nuevo problema para informarnos cuáles son los síntomas exactos para que podamos intentar reproducirlos.

Si pudiera ser útil como caso de uso, usamos ansible en una máquina ubuntu de estación de trabajo vmware, usando una carpeta compartida que apunta a una ubicación física.

Inicialmente, esta ubicación de montaje se creó por error con 777 permisos. Lo redujimos a 755.

He configurado la variable de entorno ANSIBLE_CONFIG en la ruta absoluta al nombre de archivo ansible.cfg ( /path/to/ansible.cfg ), y todavía recibo el mensaje: [WARNING] Ansible is in a world writable directory ...

$ ansible --version
 [WARNING] Ansible is in a world writable directory (/c/Users/my/path/to/ansible), ignoring it as an ansible.cfg source.
ansible 2.6.2
  config file = /path/to/ansible.cfg
  configured module search path = [u'/home/me/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/dist-packages/ansible
  executable location = /usr/bin/ansible
  python version = 2.7.12 (default, Dec  4 2017, 14:50:18) [GCC 5.4.0 20160609]

Si puede probar eso contra la rama devel o uno de los PR con backports a 2.6 o 2.5, sería genial. De lo contrario, puede esperar a que salga 2.6.3 y probarlo allí.

La documentación que formaba parte del parche tiene enlaces a información para
tanto vagabundo como windows sobre cómo montar sistemas de archivos con no mundo
directorios grabables:
https://docs.ansible.com/ansible/devel/reference_appendices/config.html#avoiding -security-risk-with-ansible-cfg-in-the-current-directory

¿Esa información no funciona para usted?

El viernes 17 de agosto de 2018 a las 3:23 a. M. Whidegroup [email protected] escribió:

Tan pronto como tengamos la versión 2.6.3, ahora debería haber una idea para hacerla
trabajar en la máquina de Windows. ¿Alguien puede aconsejar sobre la creación de
combo vagrant / ansible para que funcione correctamente especificando la ruta al archivo .cfg?

-
Recibe esto porque modificó el estado de apertura / cierre.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ansible/ansible/issues/42388#issuecomment-413823645 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAMxWhtxSRE6GQW6ZYJflqydXhrQW-FDks5uRpmLgaJpZM4VEmwB
.

Tengo Ubuntu instalado en Windows 10 junto con WSL

He agregado lo siguiente a mi / etc / environment

ANSIBLE_CONFIG = "/ etc / ansible / ansible.cfg"

Sigo recibiendo el error

¿Cómo lo hicieron funcionar aquellos que agregaron la variable de entorno ANSIBLE_CONFIG?

¿Puede abrir un nuevo ticket con detalles sobre su configuración, salida y cómo reproducir? Las últimas versiones 2.6 y 2.7 deberían funcionar sin un mensaje de advertencia si se establece ANSIBLE_CONFIG

exportar ANSIBLE_CONFIG =. / ansible.cfg

Si es un ansible.cfg en su directorio actual, no estoy seguro de por qué no lo permitiría, ya que navega allí. ¡Pero tener ANSIBLE_CONFIG es genial! Y considerar la seguridad es mucho mejor que ignorarla. ¡¡¡Gracias!!!