[Galene] Admin group creation

[Galene] Admin group creation

[Marty Betz]

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

Hello,
I'm learning a lot using Galene.  Thanks.  I've been experimenting with
creating groups programmatically using the REST admin interface.

In particular I tried to create a group using PUT method with JSON body and
it works fine for simple groups like:
{"op": [{"username": "elmer", "password": "1234567"}],"presenter": [{}],
"public": true}

But if I include a "users" list or a "wildcard-user" value, it fails with a
"description is not sanitized" error. For example this body fails:
{"op": [{"username": "elmer", "password": "1234567"}],"presenter": [{}],
"public": false, "users":{"john": {"password": "260530", "permissions":
"present"},"fred": {"password": "940934", "permissions": "present"}}}

I commented out the 3 lines of UpdateDescription() in description.go,
recompiled, and I was able to make this group just fine using the API.

if desc.Users != nil || desc.WildcardUser != nil || desc.AuthKeys != nil {
        return errors.New("description is not sanitised")
}

Why is this "sanitized" check existing in UpdateDescription().  It seems
relevant only for displaying group properties.

-Marty

[-- Attachment #2: Type: text/html, Size: 1644 bytes --]

[Galene] Re: Admin group creation

[Juliusz Chroboczek]

Hello,

> In particular I tried to create a group using PUT method with JSON body 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 admin
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.  For example, in order to display the list of users together
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 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 operations
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

[Galene] Re: Admin group creation

[Marty Betz]

[-- Attachment #1: Type: text/plain, Size: 4451 bytes --]

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":{"password":"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":{"password":"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 AM Juliusz Chroboczek <jch@irif.fr> wrote:

> Hello,
>
> > In particular I tried to create a group using PUT method with JSON body
> 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 admin
> 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.  For example, in order to display the list of users together
> 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 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 operations
> 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
>

[-- Attachment #2: Type: text/html, Size: 6100 bytes --]

[Galene] Re: Admin group creation

[Marty Betz]

[-- Attachment #1: Type: text/plain, Size: 5054 bytes --]

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 AM Marty Betz <martybetz@gmail.com> wrote:

> 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":{"password":"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":{"password":"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 AM Juliusz Chroboczek <jch@irif.fr> wrote:
>
>> Hello,
>>
>> > In particular I tried to create a group using PUT method with JSON body
>> 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 admin
>> 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.  For example, in order to display the list of users together
>> 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 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 operations
>> 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
>>
>

[-- Attachment #2: Type: text/html, Size: 6909 bytes --]

[Galene] Re: Admin group creation

[Juliusz Chroboczek]

> On further investigation, it seems the group config parameters "presenter" and
> "wildcard-user" interact in a non-trivial way.

There are two syntaxes for Galene group definitions: the old syntax, based
on pattern-matching, used in Galene 0.8 and earlier; and the new syntax,
based on a straightforward map from usernames to user descriptions, which
was introduced in Galene 0.9.

Galene still parses the old syntax for compatibility reasons.  You're
mixing the two syntaxes, which is confusing.  Please don't do that.  The
following fields are now deprecated:

  - "op", "presenter" and "other", replaced by "users";
  - "allow-subgroups" and "allow-anonymous", no longer supported.

> Having "presenter":[{}] seems to act like a wildcard user authenticator,

Yes.  That's the old syntax for what is now

   "wildcard-user": {"password":{"type":"wildcard"}, "permissions":"presenter"}

The new syntax is more verbose by design, so that you don't open your
server by mistake.

> unless another "wildcard-user" field is present.

If you mix the two syntaxes in contradictory manners, the new syntax takes
precedence over the old one.  There should be a warning in the log.

-- Juliusz

[Galene] Re: Admin group creation

[Marty Betz]

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

Thank you for the detailed information. yes, I did have the wrong mental
model.

> The new syntax is more verbose by design, so that you don't open your
> server by mistake.

I like the new syntax because it is more consistent and has fewer shortcuts
with unexpected results.
-Marty


On Mon, Dec 2, 2024 at 11:12 AM Juliusz Chroboczek <jch@irif.fr> wrote:

> > On further investigation, it seems the group config parameters
> "presenter" and
> > "wildcard-user" interact in a non-trivial way.
>
> There are two syntaxes for Galene group definitions: the old syntax, based
> on pattern-matching, used in Galene 0.8 and earlier; and the new syntax,
> based on a straightforward map from usernames to user descriptions, which
> was introduced in Galene 0.9.
>
> Galene still parses the old syntax for compatibility reasons.  You're
> mixing the two syntaxes, which is confusing.  Please don't do that.  The
> following fields are now deprecated:
>
>   - "op", "presenter" and "other", replaced by "users";
>   - "allow-subgroups" and "allow-anonymous", no longer supported.
>
> > Having "presenter":[{}] seems to act like a wildcard user authenticator,
>
> Yes.  That's the old syntax for what is now
>
>    "wildcard-user": {"password":{"type":"wildcard"},
> "permissions":"presenter"}
>
> The new syntax is more verbose by design, so that you don't open your
> server by mistake.
>
> > unless another "wildcard-user" field is present.
>
> If you mix the two syntaxes in contradictory manners, the new syntax takes
> precedence over the old one.  There should be a warning in the log.
>
> -- Juliusz
>
>

[-- Attachment #2: Type: text/html, Size: 2278 bytes --]