From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass (mailfrom) smtp.mailfrom=irif.fr (client-ip=2001:660:3301:8000::1:2; helo=korolev.univ-paris7.fr; envelope-from=jch@irif.fr; receiver=) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=irif.fr header.i=@irif.fr header.a=rsa-sha256 header.s=dkim-irif header.b=a+pDNci0 Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by mail.toke.dk (Postfix) with ESMTPS id 0619DA9C1B1 for ; Sat, 07 Dec 2024 13:31:39 +0100 (CET) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 4B7CVdlN016495 for ; Sat, 7 Dec 2024 13:31:39 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 5AF8F2AD3B for ; Sat, 7 Dec 2024 13:31:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=irif.fr; h= content-type:content-type:mime-version:user-agent:subject :subject:from:from:message-id:date:date:received:received; s= dkim-irif; t=1733574698; x=1734438699; bh=d+PzbqGCxrmULF+cmkSjxM eaRdAhZ/Oeh/vSReeIRO4=; b=a+pDNci0z5RkrS9u2g4vX0tI48cBpnyl6c5Umv XdxgPKf3TfC+wc483Nk9Ab2EUiQ1AHxdjfe0vrN/EgPr0aEtwcNjI6d6Vq1Rv2Fa hILdhyGaWJH+VI7KZ+XlJi0M17I/GmXkoZ1Sbdq923sVrmIHzrRWbXtz+BOfHCwS kDr5Gz6GnucVdhuKcs0nHNQRf/X8d6ug/UTeDUbf23gW2nVd+DAqEO0xnpYSUAGB 8g9IZjLoH6Bg8/h2T+Erxpf1GLCPU6V+FrPna7eEUGY9eydcV93dLBmqtUE4h0cj 5Z6bDSBxGTfgJC3DUNPDS8DFK8ZPYLEG5ZZKjpjIGKo4wraQ== X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id qHWvQArpXX1I for ; Sat, 7 Dec 2024 13:31:38 +0100 (CET) Received: from pirx.irif.fr (unknown [37.175.73.168]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 16B752AE04 for ; Sat, 7 Dec 2024 13:31:37 +0100 (CET) Date: Sat, 07 Dec 2024 13:31:33 +0100 Message-ID: <87ikrvfzdm.wl-jch@irif.fr> From: Juliusz Chroboczek To: galene@lists.galene.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/29.4 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sat, 07 Dec 2024 13:31:39 +0100 (CET) X-Miltered: at korolev with ID 6754402B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 6754402B.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 6754402B.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Message-ID-Hash: EFEBXI2QG3223ZJEJGG6QKBNYOCTQZDY X-Message-ID-Hash: EFEBXI2QG3223ZJEJGG6QKBNYOCTQZDY X-MailFrom: jch@irif.fr X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Subject: [Galene] Help with subtree tokens List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hi, We need two things: 1. global admin tokens, tokens that give admin rights to the whole server; 2. a way to give out administrator (not op) powers for a hierarchy. Point (1) is so that administrators don't need to store a password in order to use galenectl, just the admin token. That's good for security, since people are unlikely to reuse tokens across sites, and also because tokens are easier to revoke than passwords. Point (2) is so that I can tell people "here's an admin token for teaching/*", and they can administer the teaching hierarchy. Here's my plan to achieve both, please let me know if it makes sense to you. # Current format of stateful tokens A stateful token currently looks like this: { "token": "Xul0t84QJlE", "group": "admin", "permissions": ["present"], "expires": "2029-10-24T15:03:00Z" } There are other fields, but they are optional. Stateful tokens are stored in the file data/var/tokens.jsonl. Creating a new token is an efficient operation, since we just append a line to the file, but modifying a token requires rewriting the whole file. Tokens are cached in main memory, so fetching a token is just a hashtable access. The protocol is designed so that other, more efficient implementations are possible if the single file ends up being a bottleneck. In particular, since a token is specific to a single group, it would be possible to have per-group token files. If you enjoy Cobol, you might also consider storing tokens in an SQL table with "token" the primary key. Every 15 minutes, we walk through the tokens list and garbage collect any tokens that have been expired for 24 hours or more. # Plan for subtree tokens A subtree token looks just like a normal token, but has the additional field "include-subgroups": { "token": "Xul0t84QJlE", "group": "teaching", "permissions": ["admin"], "expires": "2029-10-24T15:00:00Z", "include-subgroups": true } A holder of such a token is authorised not only for the groups "teaching", but also for any groups of the form "teaching/*". In particular, if they have the "admin" permission, they are allowed to create new groups under "teaching", with no restrictions. As a special case, the field "group" can be the empty string, in which case the token applies to the whole server. ## Downsides Since subtree tokens don't apply to a single group, they cannot be stored in per-group files, a global file will be required. Also, token lookup stops being a hashtable lookup, since it is required to check for tokens for supergroups of the current group. # Plan for stateless tokens It is pretty trivial to do the same for stateless (cryptographic) tokens. However, since Yunohost are the main user of stateless tokens, I'm planning to wait to get feedback from them before I implement subtree support for stateless tokens. # Comments? The above design doesn't quite seem right, but I'm unable to put my finger on what bothers me. Perhaps someone can help? -- Juliusz