Resumen

  • La capability de Amoeba tenía un puerto de servidor de 48 bits, un número de objeto de 24, un mapa de derechos de 8 y un campo de comprobación de 48; el proceso usuario podía conservarla y transferirla.
  • Una validación correcta probaba que el token cumplía la regla del servidor y contenía el derecho solicitado. No probaba quién lo portaba, qué mandato tenía, por qué actuaba ni si el efecto posterior se completó o persistió.

La pregunta estrecha que el token sí podía responder

Un proceso presentaba la capability al servidor junto con una operación. El puerto llevaba la solicitud al servicio. El número de objeto identificaba un recurso dentro del espacio del servidor. Los bits de derechos limitaban las operaciones disponibles. El campo de comprobación permitía detectar cambios no autorizados.

El mecanismo respondía así a una pregunta concreta: ¿puede el portador de esta referencia válida solicitar esta operación sobre este objeto? No respondía “¿quién es esta persona?” ni “¿aprobó la organización esta acción?”. Esa separación era funcional, no accidental. Amoeba trasladó la gestión de capabilities fuera de un gestor central del núcleo y permitió que los procesos de usuario manipularan sus referencias.

La consecuencia editorial es importante. “Credencial aceptada” suele convertirse en una etiqueta de propósito, responsabilidad y éxito. Pero un token solo puede atestiguar los hechos que su verificador realmente examina. La capability de Amoeba unía nombre y protección del objeto; no era una declaración total sobre el mundo que rodeaba la llamada.

Un formato exacto de cuatro campos

El artículo de 1986 Using Sparse Capabilities in a Distributed Operating System fija el tamaño: puerto de servidor de 48 bits, objeto de 24, derechos de 8 y control de 48. El informe de 1991 describe la división de trabajo. El núcleo usa el puerto para localizar el servidor; el servidor interpreta el resto. En un servidor de archivos, el número de objeto puede desempeñar un papel semejante al número de inode de UNIX.

El byte de derechos no contiene ocho permisos universales. Cada servicio decide qué significa cada bit para su tipo de objeto. Leer y escribir un archivo no son lo mismo que iniciar o inspeccionar un proceso. La capability solo cobra sentido junto con el contrato del servidor.

El campo de comprobación hace creíble ese contrato. El servidor conserva un valor aleatorio asociado al objeto y verifica una transformación unidireccional ligada a los derechos visibles. Un cliente puede editar los bits que ve, pero no obtiene con ello el control válido que correspondería a una autoridad mayor.

Eso no permite llamar al mecanismo inexpugnable. Su objetivo histórico era impedir la falsificación bajo los supuestos de Amoeba. No demuestra que 48 bits cumplan hoy un umbral criptográfico, y tampoco impide que alguien copie un token completo que ya es válido. El informe de 1991 admite el problema de la revelación: en un entorno inseguro puede ser necesario cifrar para que una capability no quede expuesta accidentalmente.

Atenuar es intersectar derechos

La capability inicial del propietario activaba todos los derechos. Para entregar menos, el portador podía solicitar al servidor una versión restringida. El servidor validaba el original, aplicaba una máscara al conjunto existente y emitía otra capability para el mismo objeto. El ejemplo std_restrict de la guía reduce la operación a rights &= mask.

La monotonía es la garantía: el resultado conserva o elimina derechos; no añade. Encender manualmente un bit no basta, porque el campo de control deja de coincidir.

Las fuentes también obligan a distinguir prototipo, alternativa y descripción del sistema. El texto de 1986 examina varios métodos: cifrar una combinación de derechos y constante, calcular una función unidireccional con el secreto del objeto, pedir al servidor una capability reducida y explorar funciones unidireccionales conmutativas para atenuación local. El informe de 1991 presenta la ruta asistida por el servidor. Contarlas como un solo algoritmo eliminaría el dato más interesante: el equipo estaba comparando diferentes lugares en los que podía vivir la reducción de autoridad.

También sería incorrecto atribuir el trabajo a una sola persona. El artículo de 1986 tiene como autores a Andrew S. Tanenbaum, Sape J. Mullender y Robbert van Renesse. El informe de 1991 está firmado por Tanenbaum, M. Frans Kaashoek, van Renesse y Henri E. Bal. El nombre de Tanenbaum identifica una trayectoria; no sustituye la autoría colectiva de Amoeba.

El portador puede cambiar sin que cambie el token

Copiar una capability significaba copiar su patrón de bits. El diseño no necesitaba una lista central de todos los portadores. Esto ayudaba a la delegación y a la transparencia de ubicación, pero impedía inferir la cadena de custodia desde el propio token.

Cuando el servidor acepta la capability, sabe que los campos son coherentes con el secreto actual del objeto. No sabe si el proceso la recibió del creador, la encontró en un directorio, la obtuvo de otro proceso o la copió de un lugar expuesto. Para vincular la llamada con una persona, una máquina administrada o un rol contractual hace falta evidencia adicional.

Tampoco se deduce la finalidad. Un derecho de escritura puede usarse en mantenimiento previsto, recuperación urgente o cambio no aprobado. El bit autoriza el verbo; no contiene el motivo.

La revocación conserva esa geometría. Cambiar el valor secreto almacenado por el servidor invalida las capabilities anteriores del objeto. Es una invalidación amplia del objeto, no una revocación selectiva por identidad. No localiza todas las copias ni atribuye retroactivamente las llamadas ya realizadas.

Una respuesta no cruza por sí sola otras fronteras

El éxito de una operación demuestra el resultado definido por la interfaz del servidor. No demuestra automáticamente que el cambio sobrevivió a un reinicio, llegó a cada réplica, accionó un dispositivo, completó un pago o respetó una orden de cambio.

La persistencia pertenece al sistema de almacenamiento y recuperación. El efecto físico o interservicio pertenece al componente que lo ejecuta y observa. La autorización humana pertenece a la organización. Inflar una única respuesta hasta cubrir esas capas produce un registro limpio pero una explicación falsa.

Amoeba sigue siendo valioso porque su mecanismo es legible. La capability porta autoridad sobre un objeto y nada más. Respetar esa modestia permite construir auditorías mejores alrededor de ella.

Fuentes