check-for-updates and user\group rights

Maybe it’s a silly question, but is it okay, that

system/package/update/check-for-updates

needs read+write+policy policies to work. Read is ok. Write is questioning, because this command do not change any configurations at all. But policy?

policy - policy that grants user management rights

I’m writing update automation for a big chunk of routers. Is it okay of having sich wide rights (even full user management) just for access to installed-version and latest-version variables? Maybe it should be changed\rewrittwen somehow, adding separate policy just for updating, which is very common operation?

You are completely right. It should be enough with read, to just read. and should be enough with write, to upgrade. But there are deep running issues in the policy system everywhere, we have to re-make the whole thing.

From my silly opinion, write is too much for that also. As far as I understand upgrade process, system downloads package somewhere and reboot the device. No configuration changes. But looks like that rewritiing write policy is even more doomed than rewriting policy policy. :slight_smile:

In my opinion policy should hide scripts but not enviroriment. through this menu you can give the user the ability to customize variables that are taken from scripts. I’ll give you a stupid example, I have scenarios where the user has limited access and to customize their telegram id and personal email I used a json support file. it would be nice to be able to insert them from enviroriment and with a script take them to a support memory and then restore them at restart. another solution would be to integrate the.json file as a custom page in webfig, this would solve many problems

Wow, I’d like to extend a big compliment for acknowledging that the policy system is entirely inconsistent. Did not expect that answer to be honest. :smiley:

Normis is practically minded, just sometimes in the wrong direction. :slight_smile: