Bueno, el propio memcached no tiene ninguna configuración de permisos (solo los permisos del socket de escucha). Simplemente inicie el daemon y todos los objetos de memoria que se le envíen se almacenarán según la clave. No hay distinción entre el usuario o la máquina que envía o recupera los datos, incluso puede obtener colisiones clave.
Memcached fue diseñado para ser simple y pequeño, obligando a la capa de aplicación a pensar en todo lo demás. Y originalmente diseñado para ejecutarse en la misma máquina que la aplicación. Ese diseño no cambió desde 2013.
Dicho todo esto, si un proveedor de hosting te da un socket en una máquina diferente a la que te conectas directamente a memcached, debes dejar de usar ese proveedor de hosting de inmediato. Eso es simplemente imprudente. Los proveedores de alojamiento que utilizan memcached ejecutarán un demonio de memcached diferente para cada usuario (el demonio completo es solo un par de kilobytes), usarán un proxy inverso (con autenticación) o crearán una memoria caché compatible con memcached que realmente no se ejecute memcached. / p>
Si observa lo que hace AWS :
Una capa Memcached es una capa de AWS OpsWorks que proporciona un plano para las instancias que funcionan como servidores Memcached
es decir, su caché elástica se puede usar como caché de memcached, pero no es un daemon de memcached escuchando en un socket. Y (del mismo artículo) puede ver que hay autenticación en su caché:
Grupos de seguridad personalizados
Esta configuración aparece si elige no asociar automáticamente una
grupo de seguridad incorporado de AWS OpsWorks con sus capas. Debes
Especifique qué grupo de seguridad asociar con la capa. Para más
información, vea Crear una nueva pila.
Por lo tanto, el uso de memcached como cualquier solución de red, especialmente en un entorno de alojamiento, es simplemente imprudente. Sin embargo, la mayoría de los entornos de alojamiento no están usando memcached, sino que colocan una capa desde para agregar permisos.