Matthias/conduit

Fork 0

allow_registration=false don't forbid guests, thus registration_token don't forbid the first guest to become admin #415

New issue

Open

opened 2023-12-22 09:37:24 +00:00 by Thatoo · 10 comments

Thatoo commented

2023-12-22 09:37:24 +00:00

(Migrated from gitlab.com)

Headline

How to forbid first guest to become admin instead of first registered user?

Description

I set up conduit.toml like that

allow_registration = false
registration_token = "STORNG_PASSWORD"
allow_federation = false

and thus, if I was not fast enough, I would not become admin, an other "user" would become admin even though the TOKEN was pretty strong.

Then, I realized that if I open a new private window in Firefox and I go directly to https://MYDOMAIN/element/#/home , then it would log me as a guest.

Finally I tried reintalling conduit with the same conduit.toml and to log as a guest as fast as possible going to https://MYDOMAIN/element/#/home and indeed, my guest join the admin room and became admin.

So I guess, conduit needs an other setting such as allow_guets = false to forbid guests to join the server when we don't want to.

## Headline How to forbid first guest to become admin instead of first registered user? ### Description I set up conduit.toml like that ``` allow_registration = false registration_token = "STORNG_PASSWORD" allow_federation = false ``` and thus, if I was not fast enough, I would not become admin, an other "user" would become admin even though the TOKEN was pretty strong. Then, I realized that if I open a new private window in Firefox and I go directly to https://MYDOMAIN/element/#/home , then it would log me as a guest. Finally I tried reintalling conduit with the same conduit.toml and to log as a guest as fast as possible going to https://MYDOMAIN/element/#/home and indeed, my guest join the admin room and became admin. So I guess, conduit needs an other setting such as `allow_guets = false` to forbid guests to join the server when we don't want to.

Thatoo commented

2023-12-23 10:54:22 +00:00

(Migrated from gitlab.com)

changed title from allow_registration=false don't forbid {-visitor-}s, registration_token don't forbid first {-visitor-} to become admin to allow_registration=false don't forbid {+guest+}s, registration_token don't forbid first {+guets+} to become admin

changed title from **allow_registration=false don't forbid {-visitor-}s, registration_token don't forbid first {-visitor-} to become admin** to **allow_registration=false don't forbid {+guest+}s, registration_token don't forbid first {+guets+} to become admin**

Thatoo commented

2023-12-23 10:54:22 +00:00

(Migrated from gitlab.com)

changed the description

Thatoo commented

2023-12-23 10:56:09 +00:00

(Migrated from gitlab.com)

I had a thought about an allow_guests option.
I think it should not be true/false only because the main reason we want guests to connect to a room is by invitation.
So I'd suggest something like

disabled
on invitation
enabled

I even wonder if there is a use case for disabled if "on invitation" option exists.
Setting "on invitation" option by default at install time would solve the problem of the first guest becoming admin if a user is not created fast enough. Indeed, no guest could connect before a first user is created and invite them.

I had a thought about an allow_guests option. I think it should not be true/false only because the main reason we want guests to connect to a room is by invitation. So I'd suggest something like - disabled - on invitation - enabled I even wonder if there is a use case for disabled if "on invitation" option exists. Setting "on invitation" option by default at install time would solve the problem of the first guest becoming admin if a user is not created fast enough. Indeed, no guest could connect before a first user is created and invite them.

Thatoo commented

2023-12-30 12:50:43 +00:00

(Migrated from gitlab.com)

changed title from allow_registration=false don't forbid guests{-,-} registration_token don't forbid first guets to become admin to allow_registration=false don't forbid guests{+ thus+} registration_token don't forbid first guets to become admin

changed title from **allow_registration=false don't forbid guests{-,-} registration_token don't forbid first guets to become admin** to **allow_registration=false don't forbid guests{+ thus+} registration_token don't forbid first guets to become admin**

Thatoo commented

2023-12-30 12:51:23 +00:00

(Migrated from gitlab.com)

changed title from allow_registration=false don't forbid guests thus registration_token don't forbid first guet{-s-} to become admin to allow_registration=false don't forbid guests thus registration_token don't forbid {+the +}first guet to become admin

changed title from **allow_registration=false don't forbid guests thus registration_token don't forbid first guet{-s-} to become admin** to **allow_registration=false don't forbid guests thus registration_token don't forbid {+the +}first guet to become admin**

Thatoo commented

2023-12-30 15:40:21 +00:00

(Migrated from gitlab.com)

Finally, the bigger question is about how Conduit should handle guets. SO far, it simply accept all guests whatsoever.

I think that should be an option to activate for advance user. The default option should be to accept guests who have been invited and join a (specific) room thanks to a specific URL (Token). Guests should not be able to create rooms.

What do you think?

Finally, the bigger question is about how Conduit should handle guets. SO far, it simply accept all guests whatsoever. I think that should be an option to activate for advance user. The default option should be to accept guests who have been invited and join a (specific) room thanks to a specific URL (Token). Guests should not be able to create rooms. What do you think?

lpcvoid commented

2024-01-03 15:56:25 +00:00

(Migrated from gitlab.com)

I agree that guests shouldn't be able to create rooms. I would also welcome an option for disabling guests.

On the other hand, I really don't think there's much attack surface here - if somebody sets up a server, and somebody else is faster in creating an account on the server than the person who set it up, then the server admin would see that pretty quickly and nuke it, I suppose.

I agree that guests shouldn't be able to create rooms. I would also welcome an option for disabling guests. On the other hand, I really don't think there's much attack surface here - if somebody sets up a server, and somebody else is faster in creating an account on the server than the person who set it up, then the server admin would see that pretty quickly and nuke it, I suppose.

Thatoo commented

2024-01-03 16:11:10 +00:00

(Migrated from gitlab.com)

Well someone who install Conduit for the first time, might not be surprised not to find the admin room and won't wonder about it.

Thatoo commented

2024-01-10 22:52:13 +00:00

(Migrated from gitlab.com)

changed title from allow_registration=false don't forbid guests thus registration_token don't forbid the first guet to become admin to allow_registration=false don't forbid guests{+,+} thus registration_token don't forbid the first gue{+s+}t to become admin

changed title from **allow_registration=false don't forbid guests thus registration_token don't forbid the first guet to become admin** to **allow_registration=false don't forbid guests{+,+} thus registration_token don't forbid the first gue{+s+}t to become admin**

Thatoo commented

2024-01-10 22:52:13 +00:00

(Migrated from gitlab.com)

changed the description