From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by mail.toke.dk (Postfix) with ESMTPS id F1E13A9B267 for ; Mon, 02 Dec 2024 19:02:12 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=UlAWW8h3 Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-53de880c77eso5390086e87.1 for ; Mon, 02 Dec 2024 10:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733162471; x=1733767271; darn=lists.galene.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hE1fTB6zH/27LeaAA6AuA3G2M1Hsl5PMcB4v1zFng3A=; b=UlAWW8h3NOHPmfOvMBnGOgV0PcoT98+GegopBfeSu6WgyPrdiOzSGwFV0o23eGFKn3 fnnCCCGziSBMTfXeKla+5potf7O8IDrP+8wRKOUVD3ecbYAbT70C7p/PHh3yzz664h5N mBJuekSK8FualKS8BGXl1M779OcKwLPf2qPhvVodebCeB6KAhQZ5lJfaejpYOuaSEwFy opbC4HlVyeFimdvBhL0NtEXob45mXw3nePjEZJdGyRSIqBb3johWyHO4ZSEV4cEq+dBA 4YCzlFx95kcVimB9le8Lcw0uV+rDQidMJulKSiyksKFq5lkgoc534qSIjxsqqpxB3aAK PSUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733162471; x=1733767271; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hE1fTB6zH/27LeaAA6AuA3G2M1Hsl5PMcB4v1zFng3A=; b=xMrTKWxP9MDsKYgy9wmJzNa5zlczYdrdqs1k7XSsmqnH2g5QHpZRfWcQry2HVOR4fZ Rns6SjRFJKmrpB0uvcwpIRxGHMDZhCrnAq7Ltd8vEAqRsf6rWmvampsSfLDtosQZveT2 SHiYZt+33Ae0szJxp0XdX/xhTOXVrYhMMcdxKJoBJnVdE1BLGEqkZtGoZcyVafn1k65G oSMFQnXU6kMHjOClVRpIPeM6Cu4mvY1r/LoGSFPXfc5jf6jVopipy2wmOC4TlY1ikt0j zQYyU/Ju7av0NgNpf2L/nilnY09verwrvST8r3kXDn+CTxo99ln0j0aBzm6VkTitcIqI S23w== X-Gm-Message-State: AOJu0Yy1kZ6phgKtz5U5QMFGbcHmaBDSFKq+GnoHNWEvhSdkoDhbteSI nNFyZn10kGNqQxQegvUJGmpzZanEFjrqaZDtvpwbITUkydCXwZm91x2nWdGFitE9S3MiMfKwZRG 5CFIRI9VjD4oZ1Ff18bGS/ueX9u0= X-Gm-Gg: ASbGncvw7bERbd9ZHUDejwKgu0kYKhY9AFaJn/c3KcKnlprdMSW86D8oVZ0PhLQRBzg 1KfMwDOfnHRzy74iRoRkvBRrq4I+/RhE998Zb3n444pQ4TQ7zCgB5m+YV1+jMmEyL X-Google-Smtp-Source: AGHT+IHxaZFS5PF+Qrtm1dhQa0e1sKYnKnfND2N6V60lUb4+eWWtg/UZ0dyy0Gcxl8iPIh4Y/z2a3/HTuBI6qWWVi18= X-Received: by 2002:a05:6512:3d86:b0:53d:ed05:2783 with SMTP id 2adb3069b0e04-53df00a9f7dmr13424831e87.11.1733162470265; Mon, 02 Dec 2024 10:01:10 -0800 (PST) MIME-Version: 1.0 References: <87iks2jnic.wl-jch@irif.fr> In-Reply-To: From: Marty Betz Date: Mon, 2 Dec 2024 10:00:58 -0800 Message-ID: To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary="00000000000060e0a706284d5541" Message-ID-Hash: JVV7OWO4AA5MM3GWXOTTNNBAX6GQH5B4 X-Message-ID-Hash: JVV7OWO4AA5MM3GWXOTTNNBAX6GQH5B4 X-MailFrom: martybetz@gmail.com 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 CC: galene@lists.galene.org X-Mailman-Version: 3.3.10 Precedence: list Subject: [Galene] Re: Admin group creation 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: --00000000000060e0a706284d5541 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On further investigation, it seems the group config parameters "presenter" and "wildcard-user" interact in a non-trivial way. Having "presenter":[{}] seems to act like a wildcard user authenticator, unless another "wildcard-user" field is present. Is this correct? I didn't realize the syntax "presenter":[{}] was allowing anonymous users. On Mon, Dec 2, 2024 at 9:28=E2=80=AFAM Marty Betz wro= te: > Thanks. This makes sense. I got my group creation working using the REST > api. > > Now here is my question about private groups and wildcard-users. I want a > group that authorizes only a few select users (admin, john, and larry). > > Your example group public.json looks like this: > { "op": [{"username": "admin", "password": "password"}], "presenter": > [{}], "public": true} > > So first (before using the REST api) , I tried to make a private group > manually in JSON files like this: > > { > "op": [{"username": "admin", "password": "12345"}], > "presenter": [{}], > "description": "This is a private group to test password-based > restrictions.", > "displayName": "Private 3", > > "users":{"john":{"password":"224715","permissions":"present"},"larry":{"p= assword":"925385","permissions":"present"}} > } > > Being non-public, this doesn't appear in the public list of groups. > Great. > > But, a big problem! > > Login [admin/12345] >>> logged in > Login [admin/ anything_else ] >>> "not authorized" > Login [john/224715] >>> logged in > Login [john/ anything_else ] >>> "not authorized" > Login [larry/925385] >>> logged in > Login [larry/ anything_else ] >>> "not authorized" > PROBLEM: Login [anyone_else/anything] >>> logged in > > It seems I can only stop anonymous logins by adding a wildcard user with > obscure password: > { > "op": [{"username": "admin", "password": "12345"}], > "presenter": [{}], > "description": "This is a private group to test password-based > restrictions.", > "displayName": "Private Test Group", > > "users":{"john":{"password":"224715","permissions":"present"},"larry":{"p= assword":"925385","permissions":"present"}}, > "wildcard-user":{"password":"98579223487","permissions":"present"} > } > > Login [admin/12345] >>> logged in > Login [admin/monkey] >>> "not authorized" > Login [rando/98579223487] >>> logged in > Login [rando/anything_else] >>> "not authorized" > > What am I doing wrong or do I have the wrong mental model? > -Marty > > > > On Mon, Dec 2, 2024 at 4:08=E2=80=AFAM Juliusz Chroboczek w= rote: > >> Hello, >> >> > In particular I tried to create a group using PUT method with JSON bod= y >> and it >> > works fine for simple groups >> >> Good. >> >> > But if I include a "users" list or a "wildcard-user" value, it fails >> with a >> > "description is not sanitized" error. >> >> Right. That's by design. >> >> > Why is this "sanitized" check existing in UpdateDescription(). >> >> The API splits the group description into two parts: >> >> - the "sanitised" group description itself; >> - the users' database. >> >> Every user, in turn, is split into two parts: >> >> - the user description; >> - the password. >> >> So in order to create a group, you need to make 1 + 2n requests: >> >> - create the group: PUT /api/v0/.groups/groupname >> - for every user >> - create the user: PUT /api/v0/.groups/groupname/.users/username >> - set the password: PUT >> /api/v0/.groups/groupname/.users/username/.password >> >> You use .wildcard-user for the wildcard user. >> >> The main reason why I've used this organisation is that it makes >> fine-grained access control possible: for example, a normal (non-admin) >> user is allowed to change their own password, but they're of course not >> allowed to change the rest of the group description. Conversely, an adm= in >> is allowed to change the group description, but they're not allowed to G= ET >> a password. >> >> (There are other advantages, but they're less important, so I won't bore >> you with them here.) >> >> The main drawback, of course, is that it makes some operations >> inefficient. For example, in order to display the list of users togethe= r >> with their persmissions, you need to do this: >> >> GET /api/v0/.groups/groupname/.users/ >> for every user >> GET /api/v0/.groups/groupname/.users/username >> >> (It also makes the operation non-atomic: if a user is deleted between th= e >> first and the subsequent GET, then you'll unexpectedly get a 404 error. >> Oh, well.) >> >> If it becomes a problem in the future, I'll extend the API with operatio= ns >> over collections, but until we gain more experience with the API, I'd >> rather stick to simple operations only. >> >> By the way: the main user of the API right now is the galenectl program, >> which you're find in the Galene sources. Feel free to copy-paste code >> from there. >> >> I hope this helps, >> >> -- Juliusz Chroboczek >> > --00000000000060e0a706284d5541 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On further investigation, it seems the group config parame= ters "presenter" and "wildcard-user" interact in a non-= trivial way.
Having "presenter":[{}] seems to act like a wild= card user authenticator, unless another "wildcard-user" field is = present.
Is this correct?
I didn't realize the synt= ax "presenter":[{}] was allowing anonymous users.

<= /div>

On Mon, Dec 2, 2024 at 9:28=E2=80=AFAM Marty Bet= z <martybetz@gmail.com> wr= ote:
Thanks. This makes sense. I got my group creation working using the R= EST api.

Now here is my question about private groups an= d wildcard-users. I want a group that authorizes only a few select users (a= dmin, john, and larry).

Your example group public.json looks = like this:
{ "op": = [{"username": "admin", "password": "pass= word"}], "presenter": [{}], "public": true}=

So first (before using the REST api) , I tried to make a private gr= oup manually in JSON files like this:

{
=C2=A0 =C2=A0 "op": [{"username": &= quot;admin", "password": "12345"}],
=C2=A0 =C2= =A0 "presenter": [{}],
=C2=A0 =C2=A0 "description": = "This is a private group to test password-based restrictions.",=C2=A0 =C2=A0 "displayName": "Private 3",
=C2=A0 = =C2=A0 "users":{"john":{"password":"2247= 15","permissions":"present"},"larry":{&q= uot;password":"925385","permissions":"present= "}}
}

Being non-public, this doesn't appear in th= e public list of groups.=C2=A0 Great. =C2=A0

But, = a big problem!

Login [admin/12345] =C2=A0>>> logged = in
Login [admin/ anything_else=C2=A0 ] >>> "not authorized"
Login [joh= n/224715] =C2=A0>>> logged in
Login [john/ anything_else=C2=A0 ] >>> "not authorized"
Login [lar= ry/925385] =C2=A0>>> logged in
Login [larry/ anything_else=C2=A0 ] >>> "not authorized"
PRO= BLEM:=C2=A0 Login [anyone_else/anything] >>&g= t; logged in

It seems I can only stop anonymous logins by add= ing a wildcard user with obscure password:
{
=C2=A0 =C2=A0 "op": [{"username": &= quot;admin", "password": "12345"}],
=C2=A0 =C2= =A0 "presenter": [{}],
=C2=A0 =C2=A0 "description": = "This is a private group to test password-based restrictions.",=C2=A0 =C2=A0 "displayName": "Private Test Group",=C2=A0 =C2=A0 "users":{"john":{"password":&q= uot;224715","permissions":"present"},"larry&q= uot;:{"password":"925385","permissions":"= ;present"}},
=C2=A0 =C2=A0 "wildcard-user":{"passwor= d":"98579223487","permissions":"present"= }
}

Login [admin/12345] =C2=A0>>> logged in
Lo= gin [admin/monkey] >>> "not authorized"
Login [rando/= 98579223487] >>> logged in
Login [rando/anything_else] >>= > "not authorized"

What am I doing wrong or = do I have the wrong mental model?
-Marty



On Mon, Dec 2, 2024 at 4:08=E2=80=AFAM Juliusz Chroboczek <jch@irif.fr> wrote:
Hello,

> In particular I tried to create a group using PUT method with JSON bod= y and it
> works fine for simple groups

Good.

> But if I include a "users" list or a "wildcard-user&quo= t; value, it fails with a
> "description is not sanitized" error.

Right.=C2=A0 That's by design.

> Why is this "sanitized" check existing in UpdateDescription(= ).

The API splits the group description into two parts:

=C2=A0 - the "sanitised" group description itself;
=C2=A0 - the users' database.

Every user, in turn, is split into two parts:

=C2=A0 - the user description;
=C2=A0 - the password.

So in order to create a group, you need to make 1 + 2n requests:

=C2=A0 - create the group: PUT /api/v0/.groups/groupname
=C2=A0 - for every user
=C2=A0 =C2=A0 =C2=A0- create the user: PUT /api/v0/.groups/groupname/.users= /username
=C2=A0 =C2=A0 =C2=A0- set the password: PUT /api/v0/.groups/groupname/.user= s/username/.password

You use .wildcard-user for the wildcard user.

The main reason why I've used this organisation is that it makes
fine-grained access control possible: for example, a normal (non-admin)
user is allowed to change their own password, but they're of course not=
allowed to change the rest of the group description.=C2=A0 Conversely, an a= dmin
is allowed to change the group description, but they're not allowed to = GET
a password.

(There are other advantages, but they're less important, so I won't= bore
you with them here.)

The main drawback, of course, is that it makes some operations
inefficient.=C2=A0 For example, in order to display the list of users toget= her
with their persmissions, you need to do this:

=C2=A0 GET /api/v0/.groups/groupname/.users/
=C2=A0 for every user
=C2=A0 =C2=A0 =C2=A0 GET /api/v0/.groups/groupname/.users/username

(It also makes the operation non-atomic: if a user is deleted between the first and the subsequent GET, then you'll unexpectedly get a 404 error.=
Oh, well.)

If it becomes a problem in the future, I'll extend the API with operati= ons
over collections, but until we gain more experience with the API, I'd rather stick to simple operations only.

By the way: the main user of the API right now is the galenectl program, which you're find in the Galene sources.=C2=A0 Feel free to copy-paste = code
from there.

I hope this helps,

-- Juliusz Chroboczek
--00000000000060e0a706284d5541--