Passwords and ACLs #107

Closed
opened 2026-10-27 09:33:37 +01:00 by adam · 4 comments
Owner

Two issues that seem intertwined / related

-- ISSUE: Blank guest password --------------------

Setting a blank guest password does not work for repeater (and room server).
Companion app shows the blue bar at the top "You're logged in as guest". However, stats/actions error out and no pyMC sessions/acls are registered. Room server same and does not accept messages.

If I set an actual password, like "hello", stats and actions work fine (with exception) and pymc registers an active session and acl. The exception is the owner info and telemetry.

 security:
    admin_password: secret
    allow_read_only: true
    guest_password: hello


tried:
guest_password:          (blank)
#guest_password:         (commented out)
guest_password: ''	      (empty quotes)
guest_password: null	 (null)

The four variations tried results in what looks like a successful guest login. Blue banner at top says you're logged in as guest but nothing works and no pymc sessions.

A deliberate incorrect password errors out immediately (no blue bar).


-- ISSUE: ACL ---------------------


Its my understanding ACLs should be permanent until removed.
First time login creates the ACL, (guest or admin).
When ACL exists, a blank password login will check against the ACL. If exists it logs in ok. No acl login error (or should login in as guest. ie If a blank guest password is set and no acl exists, a first time login with blank password should login and create acl as guest.)

-Guest and admin ACL login appear to both be working fine, as long as an acl exists.

-Rebooting pymc_repeater clears out all acl's.

-Currently only way a guest ACL is created, is if a guest password is set and the password is used one time.

-manually trying to remove an ACL has error (screen shot). The ACL remains visible and active until pymc restarts.

#Failed to remove client: Missing required field: public_key

Image
Image
Image

(A side note, I ran into trouble using remoteterm testing logins and acls. I think RT might have an issue with guest/acl login as well. I suggest testing this guest/acl problem with official meshcore mobile (and/or the web) client apps otherwise weird thing happens. For example, in RT, a first time guest login (to mc repeater fw v1.16) with blank password never works for me, where on mobile app blank password works fine and creates the guest acl. And then once i have ACL, RT still struggles to login as guest. Admin login seems to always work.)

Two issues that seem intertwined / related -- ISSUE: Blank guest password -------------------- Setting a blank guest password does not work for repeater (and room server). Companion app shows the blue bar at the top "You're logged in as guest". However, stats/actions error out and no pyMC sessions/acls are registered. Room server same and does not accept messages. If I set an actual password, like "hello", stats and actions work fine (with exception) and pymc registers an active session and acl. The exception is the owner info and telemetry. ``` security: admin_password: secret allow_read_only: true guest_password: hello tried: guest_password: (blank) #guest_password: (commented out) guest_password: '' (empty quotes) guest_password: null (null) ``` The four variations tried results in what looks like a successful guest login. Blue banner at top says you're logged in as guest but nothing works and no pymc sessions. A deliberate incorrect password errors out immediately (no blue bar). <br> -- ISSUE: ACL --------------------- <br><br><br> Its my understanding ACLs should be permanent until removed. First time login creates the ACL, (guest or admin). When ACL exists, a blank password login will check against the ACL. If exists it logs in ok. No acl login error (or should login in as guest. ie If a blank guest password is set and no acl exists, a first time login with blank password should login and create acl as guest.) -Guest and admin ACL login appear to both be working fine, as long as an acl exists. -Rebooting pymc_repeater clears out all acl's. -Currently only way a guest ACL is created, is if a guest password is set and the password is used one time. -manually trying to remove an ACL has error (screen shot). The ACL remains visible and active until pymc restarts. #Failed to remove client: Missing required field: public_key <img width="300" height="100" alt="Image" src="https://github.com/user-attachments/assets/a8782742-85a5-4794-8b17-7b6181fc70b1" /> <br> <img width="300" height="100" alt="Image" src="https://github.com/user-attachments/assets/6d09493a-29a7-494c-ac3b-a8bf498e3742" /> <br> <img width="1652" height="234" alt="Image" src="https://github.com/user-attachments/assets/5a076590-f207-4bbd-977f-98586ded5c07" /> (A side note, I ran into trouble using remoteterm testing logins and acls. I think RT might have an issue with guest/acl login as well. I suggest testing this guest/acl problem with official meshcore mobile (and/or the web) client apps otherwise weird thing happens. For example, in RT, a first time guest login (to mc repeater fw v1.16) with blank password never works for me, where on mobile app blank password works fine and creates the guest acl. And then once i have ACL, RT still struggles to login as guest. Admin login seems to always work.) <!-- github-sync-id:4684968938 -->
adam closed this issue 2026-10-27 09:33:37 +01:00
Author
Owner

The logins are stored in memory, much like the official firmware. If the service is restarted, the login information path session etc is lost and you’ll need to log in again.

Also, the admin login has a fairly low maximum session limit by default, so if you’re using multiple clients it may get blocked (this is by design). You can increase the maximum allowed sessions if needed.

I don’t personally use RT. the official client app has always worked fine for me. I wonder if RT isn’t fully following the specification?

The logins are stored in memory, much like the official firmware. If the service is restarted, the login information path session etc is lost and you’ll need to log in again. Also, the admin login has a fairly low maximum session limit by default, so if you’re using multiple clients it may get blocked (this is by design). You can increase the maximum allowed sessions if needed. I don’t personally use RT. the official client app has always worked fine for me. I wonder if RT isn’t fully following the specification? <!-- github-comment-id:4762995941 -->
Author
Owner

The logins are stored in memory, much like the official firmware. If the service is restarted, the login information path session etc is lost and you’ll need to log in again.

Also, the admin login has a fairly low maximum session limit by default, so if you’re using multiple clients it may get blocked (this is by design). You can increase the maximum allowed sessions if needed.

I don’t personally use RT. the official client app has always worked fine for me. I wonder if RT isn’t fully following the specification?

RT aside, when rebooting or power cycle a repeater with meshcore firmware, the existing ACL's remains intact so it seems that is stored in firmware somewhere. I'm not sure if pymc_repeater is intentional about storing acl or not, either way im fine with I just thought it might be related to the issue I was most interested in which is the guest blank password issue. I could have worded the title better I suppose.

With pymc_repeater, is guest possible without a password like it is on the meshcore firmware? (ie blank or no password entered). I heard it should be possible but I have not had any success doing so with pymc_repeater.

> The logins are stored in memory, much like the official firmware. If the service is restarted, the login information path session etc is lost and you’ll need to log in again. > > Also, the admin login has a fairly low maximum session limit by default, so if you’re using multiple clients it may get blocked (this is by design). You can increase the maximum allowed sessions if needed. > > I don’t personally use RT. the official client app has always worked fine for me. I wonder if RT isn’t fully following the specification? RT aside, when rebooting or power cycle a repeater with meshcore firmware, the existing ACL's remains intact so it seems that is stored in firmware somewhere. I'm not sure if pymc_repeater is intentional about storing acl or not, either way im fine with I just thought it might be related to the issue I was most interested in which is the guest blank password issue. I could have worded the title better I suppose. With pymc_repeater, is guest possible without a password like it is on the meshcore firmware? (ie blank or no password entered). I heard it should be possible but I have not had any success doing so with pymc_repeater. <!-- github-comment-id:4763533092 -->
Author
Owner

this was possible when first deployed, but something could have changed while updating, let me check and feed back.

this was possible when first deployed, but something could have changed while updating, let me check and feed back. <!-- github-comment-id:4776923098 -->
Author
Owner

found a solution, not sure if its best but it fixes the issue for repeater and room server guest login.

Bug 1: acl.py — blank-guest client never stored in ACL
File: openhop_repeater/repeater/handler_helpers/acl.py, lines 106-116

python
if not password:
    client = self.clients.get(pub_key)
    if client is None:
        if self.allow_read_only:
            logger.info("Blank password, allowing read-only guest access")
            return True, PERM_ACL_GUEST   # ← BUG: returns success but never creates client entry
        else:
            ...

When a new client (not in ACL) sends a blank password and allow_read_only=True, the code returns (True, PERM_ACL_GUEST) but never calls self.clients[pub_key] = ClientInfo(...). The client is unknown to the ACL, so every subsequent REQ/telemetry check in protocol_request.py fails the get_client_from_acl() lookup → "REQ from unknown client".

Compare this to password-login (lines 133-154), which properly creates the ClientInfo entry, stores the shared secret, and updates timestamps.



Bug 2: login.py — allow_read_only defaults to False for repeaters

File: openhop_repeater/repeater/handler_helpers/login.py, line 98

python
"allow_read_only": security.get("allow_read_only", False),

For repeaters this hard-codes False as the default. For room servers (line 87) it defaults to True. This means even with guest_password: '', blank login is rejected by Bug 1's early path.


#######################################

Fix for acl.py (lines 106-116):

python
    if not password:
        client = self.clients.get(pub_key)
        if client is None:
            if self.allow_read_only:
                logger.info("Blank password, allowing read-only guest access")
                # Create client entry so subsequent REQ/telemetry lookups succeed
                if len(self.clients) < self.max_clients:
                    client = ClientInfo(client_identity, 0)
                    self.clients[pub_key] = client
                    client.last_timestamp = timestamp
                    client.last_activity = int(time.time())
                    client.last_login_success = int(time.time())
                    client.permissions &= ~PERM_ACL_ROLE_MASK
                    client.permissions |= PERM_ACL_GUEST
                    client.shared_secret = shared_secret
                    logger.info(f"Added read-only client {pub_key[:6].hex()}...")
                else:
                    logger.warning("ACL full, cannot add client")
                    return False, 0
                return True, PERM_ACL_GUEST
            else:
                logger.info("Blank password, sender not in ACL and read-only disabled")
                return False, 0
        logger.info(f"ACL-based login for {pub_key[:6].hex()}...")
        return True, client.permissions

Fix for login.py (line 98):

Before:
    "allow_read_only": security.get("allow_read_only", False),
After:
    "allow_read_only": security.get("allow_read_only", guest_password is None),

This way if guest_password is not set, allow_read_only becomes True (blank login allowed). If guest_password IS set, it stays False (blank login rejected, must use password).

found a solution, not sure if its best but it fixes the issue for repeater and room server guest login. Bug 1: acl.py — blank-guest client never stored in ACL File: openhop_repeater/repeater/handler_helpers/acl.py, lines 106-116 python if not password: client = self.clients.get(pub_key) if client is None: if self.allow_read_only: logger.info("Blank password, allowing read-only guest access") return True, PERM_ACL_GUEST # ← BUG: returns success but never creates client entry else: ... When a new client (not in ACL) sends a blank password and allow_read_only=True, the code returns (True, PERM_ACL_GUEST) but never calls self.clients[pub_key] = ClientInfo(...). The client is unknown to the ACL, so every subsequent REQ/telemetry check in protocol_request.py fails the get_client_from_acl() lookup → "REQ from unknown client". Compare this to password-login (lines 133-154), which properly creates the ClientInfo entry, stores the shared secret, and updates timestamps. <br><br> Bug 2: login.py — allow_read_only defaults to False for repeaters File: openhop_repeater/repeater/handler_helpers/login.py, line 98 python "allow_read_only": security.get("allow_read_only", False), For repeaters this hard-codes False as the default. For room servers (line 87) it defaults to True. This means even with guest_password: '', blank login is rejected by Bug 1's early path. <br>#######################################<BR> Fix for acl.py (lines 106-116): ``` python if not password: client = self.clients.get(pub_key) if client is None: if self.allow_read_only: logger.info("Blank password, allowing read-only guest access") # Create client entry so subsequent REQ/telemetry lookups succeed if len(self.clients) < self.max_clients: client = ClientInfo(client_identity, 0) self.clients[pub_key] = client client.last_timestamp = timestamp client.last_activity = int(time.time()) client.last_login_success = int(time.time()) client.permissions &= ~PERM_ACL_ROLE_MASK client.permissions |= PERM_ACL_GUEST client.shared_secret = shared_secret logger.info(f"Added read-only client {pub_key[:6].hex()}...") else: logger.warning("ACL full, cannot add client") return False, 0 return True, PERM_ACL_GUEST else: logger.info("Blank password, sender not in ACL and read-only disabled") return False, 0 logger.info(f"ACL-based login for {pub_key[:6].hex()}...") return True, client.permissions ``` Fix for login.py (line 98): ``` Before: "allow_read_only": security.get("allow_read_only", False), After: "allow_read_only": security.get("allow_read_only", guest_password is None), ``` This way if guest_password is not set, allow_read_only becomes True (blank login allowed). If guest_password IS set, it stays False (blank login rejected, must use password). <!-- github-comment-id:4845502029 -->
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/pyMC_Repeater#107