Lorsqu'un processus obtient le droit d'émettre vers le noeud /servers/password (par exemple avec la fonction open), il peut envoyer des messages au serveur en question. L'un des RPCs qu'il peut envoyer à ce serveur est "password_check_user'. L'interface de ce RPC indique que l'appelant doit fournir un identifiant et un mot de passe. Après vérification, le serveur retourne un jeton d'authentification à l'appelant. Celui-ci peut alors l'utiliser pour prendre des privilèges lors de requêtes à des serveurs reconnaissant ce jeton
Ceci signifie que, par exemple, un serveur FTP peut être implémenté de telle sorte qu'il démarre avec aucun jeton d'authentification (il ne peut donc pas faire de requêtes à d'autres serveurs). Lorsqu'un client tentera de s'identifier, il se contentera de passer les informations au serveur "password" et de récupérer le jeton le cas échéant. En plus de rendre l'implémentation plus simple, et donc de réduire la possibilité de failles, un énorme gain en sécurité est obtenu : le serveur doit augmenter ses privilèges et non les diminuer lorsque l'utilisateur est authentifié. Bien que le résultat soit le même, les attaques de type buffer owverflow deviennent bénignes : même si l'attaquant arrive à cracker le démon ftp au cours de la phase d'authentification, il entre dans le système avec aucun privilège (au contraire d'un système unix classique, où le serveur FTP s'exécute en tant que root et abandonne ses permissions après).
De plus, aucun élément du système n'est statique : chacun peut être remplacé, ou suppléé par l'administrateur ou par les utilisateurs. Notamment, un utilisateur peut parfaitement créer et lancer son propre serveur d'authentification. Les autres serveurs refuseront de reconnaître les jetons qu'il créera en dehors du cadre des jetons "officiels" qu'il possède. Ceci permet de créer un "proxy" d'authentification, qui subdivise les ressources contrôlées par un utilisateur donné et compartimente le système.
Par exemple, supposons un serveur de mail. Il range tous les mails dans un système de fichiers ext2 dans un fichier (comme un loopback sous Linux). Le propriétaire du fichier pourrait être, disons, "application-data". On pourrait lancer un serveur ext2fs utilisant ce fichier, et s'appuyant sur un serveur d'authentification exécuté en tant qu'utilisateur. Lorsque les clients se loggent pour vérifier leurs mails, ils se voient donc attribuer des jetons d'authentification par le serveur d'authentification local. Ces jetons, reconnus par le serveur ext2fs, sont utilisables pour lire les mails, mais sont invalides dans tout le reste du système.
[traduction libre d'un extrait de l'interview de Neal Walfield, disponible ici
Note intéressante également : les différents serveurs composant un système peuvent tourner sur des systèmes physiques distincts. Ceci n'est pas encore implémenté hélas.
), des articles en faveur du port d'armes généralisé (ben oui il a pas confiance dans la police pour le protéger des Méchants Bandits, mais par contre il pense que posséder un flingue ça va les dissuader de s'en prendre à lui (à moins qu'il soit tellement présomptueux qu'il pense savoir mieux se servir d'une arme à feu que les vilains criminels)), bon je vais pas faire la liste mais c'est 
(tiens c'est marrant il est complètement contre l'état, et la loi en général, et pour le respect de la "loi" du marché, mais sauf qu'il veut des lois pour protéger le « libre logiciel » (sic), genre obliger tous les fabricants de logiciels à publier leurs sources). Bon en fait non c'est pas vraiment « marrant », c'est trop nul pour ça, c'est même pas intéressant de chercher à casser ses argumentations : elles tiennent de toute façon pas debout. N'allez pas voir son site perso[/HS]
) passé par l'Epita/tech ^^