¿Puede Mist comunicarse (a través de IPC) con una instancia geth ejecutada por otro usuario?

Soy consciente de que Mist no puede conectarse a un nodo geth en otra computadora , pero ¿qué tal una instancia geth que se ejecuta en la misma computadora pero con un usuario diferente?

Mi objetivo sería que Alice y Bob ejecuten la misma billetera (a través de Mist) en la misma caja de Linux, pero el geth siempre se ejecuta bajo el capó en segundo plano cuando se inicia la computadora, de modo que la cadena de bloques esté siempre sincronizada sin el necesidad de dejar la interfaz de usuario de Mist abierta 24/7.

Para eso, creé un usuario llamado gethy creé una carpeta compartida llamada /home/sharedque contendrá la .ethereumsubcarpeta. Luego hago estos enlaces simbólicos para todos los usuarios:

/home/geth/.ethereum -> /home/shared/.ethereum
/home/alice/.ethereum -> /home/shared/.ethereum
/home/bob/.ethereum -> /home/shared/.ethereum

Luego corro gethhaciendo:

sudo runuser -l geth -c 'nohup /home/shared/Ethereum-Wallet-linux64-0-8-1/resources/node/geth/geth > /home/geth/geth.log 2>&1 &' &

Y parece funcionar y sincronizarse bien. El problema es que cuando trato de ejecutar Mist dentro de la sesión de Alice o Bob, aparece:

[2016-08-06 15:02:36.604] [INFO] Sockets/node-ipc - Connect to {"path":"/home/alice/.ethereum/geth.ipc"}
[2016-08-06 15:02:36.621] [WARN] Sockets/node-ipc - Connection failed, retrying after 1000ms...
[2016-08-06 15:02:37.623] [WARN] Sockets/node-ipc - Connection failed, retrying after 1000ms...
[2016-08-06 15:02:38.624] [WARN] Sockets/node-ipc - Connection failed, retrying after 1000ms...
[2016-08-06 15:02:39.626] [WARN] Sockets/node-ipc - Connection failed, retrying after 1000ms...
[2016-08-06 15:02:40.626] [WARN] Sockets/node-ipc - Connection failed, retrying after 1000ms...
[2016-08-06 15:02:41.628] [WARN] Sockets/node-ipc - Connection failed, retrying after 1000ms...
[2016-08-06 15:02:42.630] [WARN] Sockets/node-ipc - Connection failed, retrying after 1000ms...

Pensé que era un problema de permisos, pero creé un grupo de Unix llamado family, puse a todos los usuarios en él (geth, alice y bob) y otorgué suficientes permisos para que todos leyeran el archivo ipc, prueba:

$ ls -lha /home/alice/.ethereum/
total 496K
drwxrwx--- 6 alice family 4.0K Aug  6 14:58 .
drwxrwsr-x 5 alice family 4.0K Aug  5 17:19 ..
drwxrwx--- 2 alice family 468K Aug  6 15:16 chaindata
drwxrwx--- 2 alice family 4.0K Aug  6 14:58 dapp
srwxrwx--- 1 geth  family    0 Aug  6 14:58 geth.ipc
drwxrwx--- 2 alice family 4.0K Aug  5 12:21 keystore
-rw-rwx--- 1 alice family   64 Aug  5 11:40 nodekey
drwxrwx--- 2 alice family 4.0K Aug  6 14:58 nodes

Sin embargo, después de realizar estos cambios en los permisos, aún no se puede conectar. ¿Qué pasa con la conexión IPC?

ACTUALIZACIÓN: Aparentemente, después de detener geth y ejecutarlo nuevamente, vuelve a crear el archivo pero con solo 600 permisos. Entonces, ¿tal vez cambiar los permisos después de que se haya creado el archivo no es suficiente, y tengo que hacer que geth cree el archivo con los permisos correctos? Traté de hacer esto haciendo dos cosas:

  1. Uso umask 022: esto no funciona, ya sea añadiéndolo /home/geth/.profileo añadiéndolo antes del lanzamiento de geth a través desudo runuser -l geth -c 'umask 022 && nohup /home/shared/Ethereum-Wallet-linux64-0-8-1/resources/node/geth/geth > /home/geth/geth.log 2>&1 &' &

  2. Usando ACL: haciendo setfacl -d --set u::rwx,g::rwx,o::- /home/shared/.ethereum. Todavía no funciona.

  3. Establecer el getid de la carpeta a través de sudo chmod g+s /home/shared/.ethereum.

Y sigue sin funcionar, gethsigue creando un archivo 600 en /home/shared/.ethereum en lugar de 660

ACTUALIZACIÓN II: ¡ Cambiando los permisos del archivo ipc para 777que funcione! ¿Por qué el 770 no funciona? Estoy confundido. No quiero usar 777 porque parece un riesgo de seguridad.

:'(

$ getfacl geth.ipc 
# file: geth.ipc
# owner: geth
# group: gatecoin
user::rwx
group::rwx
other::---

Respuestas (1)

Resolví el problema, teniendo en cuenta estos 2 puntos:

  • Estaba usando umask 022pero lo correcto hubiera sido umask 002. Sin embargo, esto todavía no funciona (tal vez porque geth codifica la máscara al crear el archivo de socket en lugar de consultar el umask predeterminado para el usuario). Como solución para esto, uso chmod 770 en el archivo de socket poco después de iniciar geth.

  • Los permisos del grupo eran correctos, pero después de agregar al usuario al mismo grupo que el usuario geth, olvidé que el usuario tenía que volver a iniciar sesión para que el cambio surtiera efecto. Después de reiniciar la computadora, todos los permisos comenzaron a funcionar.