Being able to make the permissions more granular would be very helpful. For instance, say I want an end user to have readonly access to everything, but have read/write access to the ip → kid control section, or read/write access to ip → kid control → kids page, and access via tik app.
This would allow me to set up users that can block and unblock their kids for accessing Internet when their homework is done/isn’t done, but can’t accidentally delete the dhcp client configuration, rendering their router completely inoperable.
For a simple home use-case I give a +1. Just do not use Winbox 4, as it does not support skins yey. Winbox does not fully support skins (has some bugs). WebFig works OK.
@rextended I already removed my thumbs down before you posted this reply. I chose to not vote down and explain in words.
MikroTik missed the chance to introduce a proper, modern rights and role management system with RouterOS v7. I still find the current “policy-based” permission system quite confusing. Recently, I wrote a script that was supposed to just start a container, but I had to find out through trial and error which policy was required for /container/start. The log only shows “execution error, wrong permissions” or something like that — it doesn’t even say which permissions are missing. That kind of information would be really helpful. But no — typical information hiding.
(thanks, it could have stayed at -1, but at least I'd like to know why...)
Anyway, THANKS, you reminded me that WinBox 4 can cause security issues if it ignores the skin;
in fact, this is CVE-2025-xxxxxxx. To ignore the skin, just use winbox4?
The example I always use is the "lightweight" admin that on-site. I have customers who may want to change Wi-Fi password or add a VPN user, which today requires "write" and "sensitive", which means they can also edit things like RouterOS users (well, anything).
And in future it easy to imagine RDS/ROSE use case involve a "container admin" who needs full rights to /container but should not be allow to change network setting.
In MikroTik's world, they really do lack any way to delegate admin tasks. Either you have full rights, or read-only. So a skin and only WebFig access in policy, get close – but this more a bandaid to focus less-qualified admins to allowed parts but there really is no "security" in skins.
They did give us device-mode but I don't think that the granularity folks were looking for
In fairness, it not exactly a clear-cut path from the current policy system to something "fine grain". For example, how is one to define the ACLs? While perhaps skins could be made into some enforced ACL everywhere, as noted they don't even work in WinBox4. Or, they put this into the V8 and/or the "new controller" bucket, since it's not some easy fix to core problem here.
