☰

montar y desmontar se comportan de manera diferente cuando se ejecutan bajo cron

tag-icon • tag-icon mount cron centos-6 fuse umount
montar y desmontar se comportan de manera diferente cuando se ejecutan bajo cron

Ejecuto CentOS 6 en AWS y lo que veo me desconcierta.

Hay una s3fsmontura /etc/fstabque a veces pierde su capacidad de leer y escribir. Tengo un trabajo cron que funcionó muy bien durante meses, que simplemente probaría que el montaje estaba bien cada minuto, y si alguna vez perdiera la conexión, simplemente lo umountcompartiría mount. El soporte tendía a desaparecer con más frecuencia sin carga que con carga real, por lo que esta fue una gran solución.

Por alguna razón, esto dejó de funcionar y ahora las máquinas aparecen sin poder leer/escribir desde el recurso compartido, ya que lo primero que hacen las máquinas al arrancar después del aprovisionamiento es umounty mountel recurso compartido.

Ahora el error que me sale al intentar leer es este:

cp: cannot open `/app/canary.txt' for reading: Input/output error

En el /var/log/messagesveo esto:

kernel: s3fs[3077]: segfault at e66000 ip 00007f833663d94e sp 00007ffc849c5b18
error 4 in libc-2.12.so[7f83365b4000+18a000]

Ahora, cuando ejecuto exactamente el mismo script en la consola como root, simplemente funciona perfectamente. Desmontar y montar el variador y dejarlo en estado de funcionamiento.

Mi primera suposición fue que algo en el entorno estaba causando la diferencia, así que agregué un source /root/.bash_profilea mi script, sin éxito.

La línea en /etc/fstab es un monstruo, pero esto es lo que descubrimos que funciona mejor después de muchos intentos de ajuste fino:

ourbucket /app fuse.s3fs _netdev,allow_other,endpoint=us-west-2,url=https://s3-us-west-2.amazonaws.com,use_path_request_style,use_sse,gid=1001,umask=0007,use_cache=/srv/s3fs,retries=20,parallel_count=30,connect_timeout=30,readwrite_timeout=60,stat_cache_expire=86400,max_stat_cache_size=100000 0 0

Así es como se ve el archivo cron:

* * * * * root /usr/bin/sudo /root/check_mount.sh

Lo probé con y sin sudo, ya que pensé que podría afectar el medio ambiente.

Probé muchas variaciones del script, pero la mayoría de estos comandos se usaron en un momento u otro. El mismo problema surge independientemente del tipo de umountactividad que haga.

\cp /app/canary.txt /tmp/canary.txt
retVal=$?
sleep 1
if [ ${retVal} -ne 0 ]; then
    echo "Copy failed, trying to umount"
    umount /app
    echo "umount returned $?"
    sleep 1
    echo "Trying umount -f"
    umount -f /app
    echo "umount -f returned $?"
    sleep 1
    echo "Trying fusermount -u"
    /usr/local/bin/fusermount -u /app
    echo "fusermount returned $?"
    sleep 1
    echo "Trying to mount"
    mount /app
    echo "mount returned $?"
    sleep 1
    echo "Trying copy after mount"
    \cp /app/canary.txt /tmp/canary.txt
fi

Este guión estaba inicialmente en python, con las piezas clave simplemente desembolsando os.system, pero quería eliminar eso de la ecuación. Estaba dando los mismos problemas.

Respuesta1

Aquí está mi solución completa:

Primero audité visualmente audit.log. Para captar las cosas correctas y solo las cosas correctas, solía audit2allowcrear una política y una regla de aplicación de tipos.

grep mount /var/log/audit/audit.log | audit2allow -R -M mounts3fs

Busco la montura para obtener solo las cosas correctas.

Esto creó unmontes3fs.ppymontes3fs.tearchivo. Elmontes3fs.teSe ve como esto:

policy_module(mounts3fs, 1.0)

require {
    type file_t;
    type var_t;
    type mount_t;
    type cert_t;
    class dir { write remove_name add_name };
    class file { create unlink link setattr };
}

#============= mount_t ==============
#!!!! The source type 'mount_t' can write to a 'dir' of the following types:
# user_home_t, etc_runtime_t, var_run_t, mount_var_run_t, mount_tmp_t, user_home_dir_t, etc_t, nfs_t, tmpfs_t, tmp_t, var_t

allow mount_t cert_t:dir { write remove_name add_name };
allow mount_t cert_t:file { create unlink };
allow mount_t file_t:dir { remove_name add_name };
allow mount_t file_t:file { unlink link setattr };
allow mount_t var_t:file link;

Para instalar la política, ejecuto esto:

semodule -i mounts3fs.pp

Descubrí que eso no era suficiente para ciertas operaciones, así que creé una política adicional como esta:

module s3fs 1.0;

require {
    type file_t;
    type mount_t;
    class dir create;
    class file create;
}

#============= mount_t ==============

#!!!! This avc is allowed in the current policy
allow mount_t file_t:dir create;
allow mount_t file_t:file create;

selinuxTodavía puedo ir directo al infierno.

información relacionada