sergio/takana

Pedido tras instalar zsh: «no me funciona chsh». Dos capas, y sólo la primera es un arreglo.

1. /etc/shells NO EXISTÍA en la caja, y shadow rechaza cualquier shell que no esté listado (para un
   usuario normal es rechazo duro, no aviso). Escrito con lo que existe, comprobado -x uno por uno,
   en vez de copiar la lista de otra distro: un shell listado que no está deja a quien lo elija sin
   poder entrar, y eso no se ve hasta el siguiente login. Con eso `chsh -s /bin/zsh sergio` va, y
   `su - sergio` entra con zsh 5.9.

2. ⚠ Pero sergio sigue sin poder cambiárselo él mismo: `su sergio -c "chsh …"` ⇒ «Cannot change ID
   to root». Los cinco binarios de shadow que necesitan setuid (chsh, passwd, su, chfn, newgrp)
   salen del store r-xr-xr-x, porque la receta lleva --disable-account-tools-setuid heredado del
   APKBUILD de Alpine (allá los hace setuid el empaquetado, no el configure). Y debajo hay otra
   capa: of_tree sólo hashea el bit de EJECUCIÓN (mode & 0o111), así que el modelo de artefactos
   hoy no puede ni expresar ni garantizar un setuid — aunque la receta lo pusiera, el hash no lo
   cubriría y nadie notaría si se pierde o aparece.

Quitar la bandera no alcanza y no es un arreglo de receta: es una decisión de seguridad. Anotada
en la propia receta y en SDD 28 §5.11, sin decidir.

El comentario va en la cabecera de la receta y NO mueve su hash: comprobado antes y después,
b3:843e9098… las dos veces (los comentarios fuera de [build.phases] no entran en hash_inputs).

diff --git a/docs/28-servidor-de-produccion.md b/docs/28-servidor-de-produccion.md
index ca6f7a28..74c4eb9d 100644
--- a/docs/28-servidor-de-produccion.md
+++ b/docs/28-servidor-de-produccion.md
@@ -761,6 +761,43 @@ sueltos en perezoso y el estado borrado. Ahora: `zsh 5.9` en `/bin/zsh`, 1296 fi
 `dirname(store)/work`). Devuelto a `sergio`. El guion de publicar ya exporta `TAKANA_WORK` para
 esto; `install` a secas no tiene esa defensa, y es deuda anotada.
 
+### 5.11 `chsh` no funcionaba, y las dos razones eran distintas *(2026-09-21)*
+
+Pedido del usuario después de instalar zsh. Dos capas, y sólo la primera es un arreglo.
+
+**1. `/etc/shells` no existía.** `chsh` de shadow rechaza cualquier shell que no esté en esa lista
+—para un usuario normal es un rechazo duro, no un aviso— y el fichero **no estaba en la caja**.
+Escrito con lo que EXISTE, comprobado `-x` uno por uno (`/bin/sh`, `/bin/ash`, `/bin/bash`,
+`/bin/zsh`) y no copiado de otra distro: *un shell listado que no está deja a quien lo elija sin
+poder entrar, y eso no se descubre hasta el siguiente login*. Con eso, `chsh -s /bin/zsh sergio`
+funciona y `su - sergio` entra con `zsh 5.9`.
+
+**2. ⚠ Pero `sergio` sigue sin poder cambiárselo él mismo, y eso no es un fichero que falte.**
+
+```
+$ su sergio -c "chsh -s /bin/bash"
+Cannot change ID to root.
+```
+
+Los cinco binarios de shadow que necesitan setuid root —`chsh`, `passwd`, `su`, `chfn`,
+`newgrp`— salen del store como **`r-xr-xr-x`**. No es que la hidratación pierda el bit: la receta
+lleva **`--disable-account-tools-setuid`**, heredado del APKBUILD de Alpine (donde esos binarios
+los hace setuid el *empaquetado*, no el configure — y acá no hay quien se lo reponga).
+
+Y hay una segunda capa debajo: **`ArtifactHash::of_tree` sólo hashea el bit de EJECUCIÓN**
+(`mode & 0o111`). O sea que hoy el modelo de artefactos **no puede ni expresar ni garantizar** un
+binario setuid: aunque la receta lo pusiera, el hash no lo cubriría y nadie notaría si se pierde o
+si aparece.
+
+⇒ **Quitar la bandera no alcanza y no es un arreglo de receta: es una decisión de seguridad.** Un
+setuid root en una distro de artefactos sellados necesita contestar quién lo pone, quién lo
+verifica y qué significa que el hash no lo cubra. Anotado, sin decidir.
+
+Consecuencia práctica mientras tanto: **los cambios de shell y de contraseña en esta caja los hace
+root**. Y una observación que sale de mirar esto: no hay `/etc/shadow`; las contraseñas viven en
+`/etc/passwd`, que es legible por todos, con hash DES clásico. No lo toqué — es su propia unidad de
+trabajo y afecta al arranque de la caja.
+
 ---
 
 ## 6. La mudanza como experimento: el criterio de borrado
diff --git a/recipes/shadow.toml b/recipes/shadow.toml
index b068e796..db8987dd 100644
--- a/recipes/shadow.toml
+++ b/recipes/shadow.toml
@@ -1,6 +1,22 @@
 # Importada de Alpine aports por `takana import-alpine` (Etapa G). PUNTO DE PARTIDA — pero
 # YA trae los parches de musl de Alpine (lo que un import de nix pierde). Pendiente: el
 # sha256 del tarball (el wrapper lo calcula), y adaptar build/install del shell de abuild.
+#
+# ⚠ CONSECUENCIA MEDIDA DE `--disable-account-tools-setuid` (2026-09-21, caja `takana`): para un
+# usuario que NO sea root, `chsh`, `passwd`, `su`, `chfn` y `newgrp` **no funcionan**. El síntoma
+# no menciona setuid por ningún lado:
+#
+#     $ su sergio -c "chsh -s /bin/bash"
+#     Cannot change ID to root.
+#
+# La bandera vino en el import de Alpine —allá esos binarios los hace setuid el empaquetado, no el
+# configure— y acá no hay quien se lo reponga: el artefacto sale `r-xr-xr-x` del store. Y aunque la
+# receta lo pusiera, **`ArtifactHash::of_tree` sólo hashea el bit de EJECUCIÓN** (`mode & 0o111`),
+# así que hoy el modelo de artefactos no puede ni expresar ni garantizar un binario setuid.
+#
+# Quitar la bandera NO alcanza y además es una decisión de seguridad, no un arreglo de receta:
+# un setuid root en una distro de artefactos sellados necesita su propia conversación (¿quién lo
+# pone, quién lo verifica, y qué pasa cuando el hash no lo cubre?). Ver SDD 28 §5.11.
 name    = "shadow"
 version = "4.18.0"
 license = "BSD-2-Clause"