Hardware: VM in a computer YunoHost version: 3.5.2.2 I have access to my server : Through SSH and through the webadmin Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : no, apart from traffic being forwarded by main machine to yunohost VM
Description of my issue
I think I have the same issue that is also described in this last post. Is there any precision on that situation?
I have installed mailman as public application (I verified it is public in /etc/yunohost/apps/mailman/settings.yml and it is indeed set is_public: '1').
I can visit lists.mydomain.tld/mailman/listinfo without logging in, and also most lists’ subscription page lists.mydomain.tld/mailman/listinfo/mylist. But if I want to access the admin interface of a list, I need to login as yunohost user (also it’s weird but some lists redirect to login page even for accessing the subscription page).
So the question for me is, why should one log in as yunohost user to administrate a list (since you then need to enter the list’s administration password)? This seems contrary to the idea of the app being public, no?
It would be nice not to need to create yunohost accounts on the server just for people to be allowed to administrate a mailing list. Also it’s a bit annoying for them to have in a way to log in twice to enter the administration page (once as yunohost user, then with the list’s password).
Is there a way to get around this current limitation (or bug)?
it’s a bit complex but that’s to notice is that it adds the /listinfo, /subscribe, /private, … pages as public (if public is chose) but never add the /admin part.
Yes and no : the way I saw it was more that if the app is private, only logged-in users would be able to access the /listinfo (and any other mailman pages). But clearly there’s an ambiguity with “what about the admin pages ?”
I paid attention though to never set the admin pages as public because I don’t really trust the security of mailman … But I also understand that you may want to provide public access to this page, I don’t have a strong opinion for this
A quick and dirty fix can be to edit /etc/yunohost/apps/mailman/settings.yml and add some regex to allow access to the admin pages. Then once you’re happy with it, you can try to run yunohost app ssowatconf and check in your browser if that does the trick
Alternatively, the app could be changed to have an additional setting to define if the admin is publicly exposed - or the current is_public system could have 3 choices like : entirely private, list public, list and admin public
Hey @Aleks thanks a lot for your detailed answer.
Maybe I’ll try your suggestion to change the regex in settings.yml but I’m a bit reluctant to have such kind of fix/customization in production, because then it’s something to maintain with time and to pay attention to, but it’s good to know a possible solution
About your choice of keeping admin page protected by yunohost authentication, I’m not sure what to think of it. I don’t really know what you mean by not trusting the security of mailman, so it’s hard for me to have an opinion on that side.
But my preoccupation is to have to create yunohost account(s) for person (or maybe for a group of a lot of people who handle their mailing list collectively), because creating such account not only gives them access to mailman but to all yunohost services. If there was an easy way to create accounts that are excluded from other services like nextcloud, mail… that could be an option, but as for what I know, I’m not so fond of having to create yunohost accounts for person who are just using mailman.
But maybe that’s still the best option at the moment.
Your idea of creating 3 levels of “publicness” while installing sounds like a nice solution to me.
Also digging into it today I was thinking it would be nice to be able to modify the public/private status of the app without having to reinstall it completely (but that’s probably a mechanism that would be useful to many apps in fact).
From what I understand the change in the script to allow to have different levels of publicness is pretty minimal, the main change is in line https://github.com/YunoHost-Apps/mailman_ynh/blob/master/scripts/install#L50 that should be changed from for word in listinfo subscribe private roster archives
to for word in listinfo subscribe private roster archives admin
depending on the chosen setup.
And then create the interface to prompt properly in CLI and web interface what mode of installation should be chosen.
I could try to work on this in the coming months if I find some time and manage to repair my destroyed developing environment
Actually, looking a bit deeper, there is also some fixes to do on the current regexp because if the mailing list names contain numbers yunohost will ask authentication even for viewing the list info page.
Also some links in mailman pages have a trailing slash (e.g. https://lists.mydomain.tld/mailman/private/mylist/ to view the archive on some lists) which redirect to login page when clicked, but is accessible publicly if I just remove the trailing slash.
Not really anything in particular, just that mailman2 is getting old, and the password management is not really up-to-date with the best practice (afaik it’s just an hash) and there’s no bruteforce countermeasure (though nowadays we could use the fail2ban helpers to integrate something like this).
In the use case I had in mind, it was just not such a big deal because I was not imagining having admins / moderator that wouldnt be yunohost users. But I do understand your usecase …
Hmmm there’s a permission mechanism that would allow to do that, but you gotta be careful each time you add a new user or app that the permissions are as you expect … Might become easier once we have an UI for the group permission mechanism coming in 3.7 (which will only ship the backend / CLI for it) …
