WordPress: ¿permisos reforzados con actualizaciones automáticas?

3 minutos de lectura

avatar de usuario
Jenny Shoars

¿Hay alguna manera de permitir que WordPress se actualice automáticamente sin dejar de usar permisos reforzados?

Parece que la configuración de seguridad recomendada para WordPress es usar permisos endurecidos, que se logran principalmente utilizando los permisos proporcionados en esta respuesta. Sin embargo, estos permisos hacen que WordPress no pueda actualizarse automáticamente o usar la actualización a través de la interfaz web del administrador, lo que genera un error:

Downloading update from https://downloads.wordpress.org/release/wordpress-x.x.x-partial-x.zip…

Unpacking the update…

The update cannot be installed because we will be unable to copy some files. This is usually due to inconsistent file permissions.: wp-admin/includes/update-core.php

Installation Failed

Al permitir que el servidor web se actualice update-core.php violamos los permisos endurecidos (por lo que puedo decir). Desafortunadamente, sin actualizaciones automáticas, también tenemos el problema de que no recibimos actualizaciones de seguridad automáticas, lo que genera otro problema de seguridad. ¿Hay alguna forma de permitir actualizaciones automáticas sin necesidad de permisos débiles? ¿Cuáles son los permisos más estrictos que se pueden usar sin dejar de permitir las actualizaciones automáticas? ¿Son lo suficientemente fuertes?

los Fortalecimiento de WordPress La guía describe qué es una configuración segura y recomienda actualizaciones automáticas, pero convenientemente omite que la primera no funciona con ellas.

Que yo sepa, cada administrador tiene que tomar una decisión muy desagradable:

  1. Mantenga los permisos reforzados, lo que requiere estar al tanto de cada actualización menor y cambiar los permisos de un lado a otro para ejecutarla.
  2. Afloje los permisos de manera no documentada y arriesgue las mayores inseguridades asociadas

Como alguien que se ocupa principalmente de la automatización, personalmente no puedo respaldar el enfoque manual. Parece un riesgo menor, pero eso es solo si nunca deja una actualización desatendida durante una semana o dos. Entonces podría decirse que el riesgo es mayor debido a las vulnerabilidades sin parches de lo que hubiera sido por los permisos más flexibles.

Aquí está el extracto que uso para cambiar al modo “inseguro” durante los pocos segundos que lleva actualizar (y que usaré hasta que surja algo mejor o termine mi paciencia con este enfoque manual):

sudo chown -R <wordpress_user> <wp_rootdir>; read; sudo chown -R <myuser> <wp_rootdir>

Cambia el propietario de todo al proceso que ejecuta WordPress y usa el comando “leer” solo para esperar hasta que presione cualquier botón y luego restaurar al propietario original.

TL;DL: No, sólo existe la elección de dos extremidades.

  • Creo que esta es la solución al problema que tengo. ¿Cómo sé cuál es el usuario de wordpress? Hay, por lo que puedo decir, solo un usuario en mi servidor (con el que inicio sesión). Supongo que se trata de .

    – tobogranito

    10 oct 2019 a las 13:46

  • @tobogranyte Enumeras todos los procesos con ps -ef y busque el usuario (primera columna) que está ejecutando los procesos de WordPress. Creo que normalmente tendrían php en el nombre.

    – Garra interior

    14 oct 2019 a las 16:04

  • Cuando hago eso, la primera columna es un número, no un ID de usuario.

    – tobogranito

    15 oct 2019 a las 17:36

  • Extraño, tal vez una versión diferente de Linux. Mire la parte superior de la lista para ver los nombres de los encabezados y saber qué columna significa qué. Estás buscando el que se titula UID.

    – Garra interior

    16 oct 2019 a las 18:21

  • Esta parece ser una mejor solución que otras que necesitan cambiar archivos y permisos de directorio.

    – Akasha

    18 de julio de 2021 a las 5:40

¿Ha sido útil esta solución?