No, the plan is to do something specific to Yunohost, and generalise it when users request new features. I try to avoid generalising from a single example.
Ok.
For the teachers, maybe I still overlook something? I would currently see only this way:
To run separate galene-ldap instances configured with different permissions for the same (e.g. teacher) groups. And managing access would then be by keeping track of the keys, to add the respective sets of keys to the different galene groups?
EDIT:
where the user has to understand LDAP syntax
Should be an admin or package maintainer, though.
I can see quite a few solutions. We could for example use a different LDAP attribute for different groups, so a teacher would have an attribute that says its a normal user, and a specific attribute that says he’s an op in teacher groups.
But I think there’s a simpler solution. A teacher could simply be an ordinary user, and you would give out a stateful (revocable) token, valid for the whole term, to every teacher for the courses they are teaching.
An even simpler solution is to give all staff members full rights in all groups, and politely ask them not to be abusive. It works really well in practice. And it’s actually convenient: at online staff meetings, you ask for a volunteer to moderate, and you don’t need to do anything special to give them moderation rights. (Not a problem now, since we’ve got the /op command to temporarily give rights to a user, and we can give out a token with op rights, but during Covid Galene was less mature, and we had to edit configuration files on the server.)
I wonder why you see those as solutions. They all seem to add unnessary work for everyone.
Because the users are already assigned to system permission groups, and all that is missing is to define galene group permissions based on the system groups.
Regardless of the underlying representation, there will always be some dedicated tool (command) to check the authorization, I don’t know why you want to implement and maintain these things with galene.
For example, even though LDAP is a complicated beast, for yunohost this specific command seems to do all the magic to get the list of authorized groups: (as set up by devs/package maintainers)
# bind with user's credentials (-x -W -D) and
# refine a base search (-b) to memberOf lines
ldapsearch -x -W -D "uid=${user_id},ou=users,dc=yunohost,dc=org" \
-b "uid=${user_id},ou=users,dc=yunohost,dc=org" \
memberOf \
| grep ^memberOf \
| sed 's/^memberOf: cn=//; s/,ou=groups,dc=yunohost,dc=org$//'
The problem in galene is that, as far as I understand, there is no way in galene group.json config files to assign externaly authorized users, and groups of users, to permissions for the specific galene group.
I don’t think galene group permissions can be generalized to application wide permissions, as it seems galene-ldap currently attempted. Permissions are group-specifc.
And think something like a generic galene-auth (possibly replacing galene-ldap and maybe others) that calls configurable external command lines may safe you work, while supporting integration in much more places.
as far as I understand, there is no way in galene group.json config files to assign externaly authorized users, and groups of users, to permissions for the specific galene group.
Yes, that is by design. The idea is that for simple deployments, you use Galene’s built-in authorisation mechanism, and if you need to access an external source of truth, you write an authrosation server, such as galene-ldap. The advantage is increased security: the Galene server can run with limited permissions (for example in a chroot), only the auth server needs to be able to speak to the LDAP, SQL, etc. server.
Regardless of the underlying representation, there will always be some dedicated tool (command) to check the authorization, I don’t know why you want to implement and maintain these things with galene.
Security. By running an external command, you make the system more complex, which increases the attack surface. For example, if galene-ldap were running ldapsearch, there would be two levels of quoting (shell + LDAP), so there would be a risk of XKCD 327.
I don’t think galene group permissions can be generalized to application wide permissions, as it seems galene-ldap currently attempted. Permissions are group-specific.
That’s by design. Galene’s built-in permissions have strictly limited scope, for anything more complex, you’re expected to delegate auth to an external server.
Hm, in my testing I’ve now hit a related further problem. Adding an “authServer” and (one) “authKeys” to a group.json file broke all its other user definitions. With the following config I always got 401 errors for “users”: and “wildcard-user”: (while an ldap op was properly logged in and did /unlock) , unless I removed authServer and authKeys from the config, then I could log in with user “op”, /unlock, and then login with arbitrary further users.
{
"public":true,
"allow-recording": false,
"auto-subgroups": true,
"autolock": true,
"autokick": true,
"users":{
"op": {"password":"...", "permissions": "op"}
},
"wildcard-user": {"password": {"type": "wildcard"}, "permissions": "present"},
"authServer": "https://.../auth/",
"authKeys": [
{"alg":"HS256","k":"...","key_ops":["sign","verify"],"kty":"oct"}
]
}
Concerning supporting an external auth command, to me it seems that galene-ldap would have to sanitize the user input for LDAP queries anyway (LDAP Injection Prevention - OWASP Cheat Sheet Series). It probably should also allow only a limited set of characters in usernames and passwords (no control chars) anyway. And then, adding shell escaping (or better returning errors) for some external command call, still looks simpler and more flexibly configurable then requiring to develop and maintain own auth-server logic, just to get galene groups configured:
https://stackoverflow.com/questions/4273074/sanitize-user-input-in-bash-for-security-purposes
https://stackoverflow.com/questions/89609/in-a-bash-script-how-do-i-sanitize-user-input
Hm, in my testing I’ve now hit a related further problem. Adding an “authServer” and (one) “authKeys” to a group.json file broke all its other user definitions.
You want to set passwordFallback to true.
Hm, I’ve produced an error 500 with it here, by reducing the password stuff to this at the end of above config:
],
"passwordFallback": true,
"wildcard-user": {"password": {"type": "wildcard"}, "permissions": "present"}
}
log:
galene[739494]: 2026/11/01 17:30:20 HTTP server error: json: unknown field "passwordFallback"
Hm, same log if adding it to the wildcart-user dict, but it gets accepted as key property: ..."kty":"oct","passwordFallback": true}.
However, I’m still seeing 401 on wildcard login attempts.
Oh, it’s a galene_ldap option.
Tested it there, and now ldap users can /unlock public login to such groups, really nice!
I’m glad it works for you.
So let’s think together: what is missing in galene-ldap to fully meet your needs?
Hm, well I think there are a couple of smaller changes with a really noticeable positive effect. I’ll just list my toughts here.
What’s mising most in the context of Yunohost for galene_ldap seems the single-sign-on (SSO) bit.
- simplest (proxy auth)
- userid taken from a “trusted proxy header” (e.g. config ‘YNH_USER’, SSO/LDAP integration | Yunohost)
- corresponding user’s groups read from ldap (without a user-bind)
- or complex (OIDC)
- full protocol with registration secrets, redirection, callbacks etc. and role claims for groups/permissions
Both would seem to need a way to filter and map existing groups/claims, e.g.:
grep -o 's/^acceptedgroupname$/"galene","permission","list"/'
The standard options for LDAP lookups seem quite generic, regardless if using a library or the ldapsearch command (bind config, base filter, ldap search ‘(…)’, attribute selection, local mapping).
Generally of course, group lookups must never be made for non-authenticated, user-supplied (wildcard) usernames (fallback logins).
I think the ldapsearch command line examples can serve as good examples for library call configurations, at least.
Other implementation examples:
LDAP · Sync-in
[Ent] LDAP / AD - Pydio Documentation
Besides the ldap:
-
users with /unlock permission (op?) would benefit from a permanent status indication to see if the userlist is currently locked or open (maybe also show the status on the outer login page?)
-
behind a reverse proxy: /identify only shows the proxy IP, even though “proxyURL” is set (another “trusted proxy header” configuration needed? to get real IP, e.g. X-Real-IP/X-Forwarded-For)
-
autokick could start to make sense if it only kicked after a reasonably short timeout without any op re-connecting, e.g. after connection drops or network changes, default maybe 45 seconds?
-
wildcard passwords should allow empty passwords, while still requiring a (nick)name (as long as allow-anonymous is false)
-
missing an option to disallow /invite (token link access) for a login-based group
-
index page: title would align better with other content if left aligned, especially on larger screens
-
index page: the groups listed (in
<tr>table rows) would need some spacing between them (item separation on small screens), and the groups’ displayName (left) should display at top of the table cell (not vertically centered). -
galene.html room page: the title could be
<a class="galene-header" href="/" target="_blank">Galène</a>, to provide a link to the index page (in a new _blank tab, to avoid disconnecting current connection)
tmb, for upstream issues with Galene, you’ll be better served if you write to the Galene mailing list https://lists.galene.org or file issues on GitHub. And since you seem to be well versed in UI issues, perhaps you’d consider sending us patches to the CSS?
Unfortunately not versed with frontend development, had actually tried to modify the css but were not able to, I’m sorry. Could only do the last html link with a sed -i in my install. I’m willing to help, but better at adjusting the yunohost side.
I posted all the points I came across, as you asked, and think deserve to know the whole result/feedback.
I posted all the points I came across, as you asked, and think deserve to know the whole result/feed
Well, I’d much rather be replying on the mailing list, since there’s a lot
of knowledgeable people there, but as you wish.
users with /unlock permission (op?) would benefit from a permanent status indication to see if the userlist is currently locked or open (maybe also show the status on the outer login page?)
That’s already been requested. Agreed.
behind a reverse proxy: /identify only shows the proxy IP, even though “proxyURL” is set (another “trusted proxy header” configuration needed? to get real IP, e.g. X-Real-IP/X-Forwarded-For)
I recommend running Galene exposed to the Internet. I have no objection if somebody implements it, but won’t implement it myself.
autokick could start to make sense if it only kicked after a reasonably short timeout without any op re-connecting, e.g. after connection drops or network changes, default maybe 45 seconds?
I agree. I’m probably not going to implement it myself.
wildcard passwords should allow empty passwords, while still requiring a (nick)name (as long as allow-anonymous is false)
allow-anonymous does not work in recent versions of Galene, the functionality has been removed (you should have seen a warning in your logs). Anonymous users are always allowed.
missing an option to disallow /invite (token link access) for a login-based group
By default, /invite is only allowed for ops. Allowing /invite requires setting the unrestricted tokens option.
index page: title would align better with other content if left aligned, especially on larger screens
I think it would be better to center the other content.
index page: the groups listed (in table rows) would need some spacing between them (item separation on small screens), and the groups’ displayName (left) should display at top of the table cell (not vertically centered).
I’m not sure what you mean.
galene.html room page: the title could be Galène, to provide a link to the index page (in a new _blank tab, to avoid disconnecting current connection)
I’d accept a patch to do that.
All right, most to be continued elsewhere.
I recommend running Galene exposed to the Internet.
In yunohost, however, it’s always runnig behind an nginx reverse-proxy (providing X-Real-IP header, and SSO headers like YNH_USER etc.).
option to disallow /invite (token link access) for a login-based group
By default, /invite is only allowed for ops.
(The original problem from above.) With ldap users it’s currently all or nothing, so op permission needs to be given to all yunohost groups (teachers no problem, but can’t use ldap for student groups).