Some very useful apps depend on the ability to run system calls. But for those system calls to be allowed, the commands must be added to /opt/z-way-server/automation/.syscommands manually by the local system administrator. What's more, it's not persistent between ZWay upgrades, so for each upgrade, one has to manually backup or reenter all its content.

Both from a user perspective and a security perspective, this is less than ideal. The user perspective is pretty obvious: unexperienced users will find the manual change of that file intimidating or confusing, and the rest of us will find it slightly tedious – although it's a quick operation. And when it has to be redone or copied for every upgrade, it gets even more tedious.

From a security perspective, the issue is that whatever is included in .syscommands can be run by any app – also malicious ones. This is not a major issue though, as all apps in the store are inspected by ZWay staff before it's approved.

My suggestion is to handle this issue more like it's done on for example Android, where each app has to ask for specific permissions, and the granting (or decline) of those permissions are associated with the app instance itself. So if some app needs to run ping, for instance, the user who installs the app needs to grant it the permission to run that specific system command. Any other app which also needs to run ping will also have to ask for permission to run ping, regardless of whether other apps have been granted the same permission. This should be persistent through system upgrades (but perhaps not through upgrades of the app itself – arguments could be made both ways there).

This would make it much easier for the users installing apps that depend on certain system commands and upgrading the system afterwards, and it would make a slight improvement to the security when permissions are app specific.

From a security perspective, the issue is that whatever is included in .syscommands can be run by any app – also malicious ones. This is not a major issue though, as all apps in the store are inspected by ZWay staff before it's approved.

My suggestion is to handle this issue more like it's done on for example Android, where each app has to ask for specific permissions, and the granting (or decline) of those permissions are associated with the app instance itself. So if some app needs to run ping, for instance, the user who installs the app needs to grant it the permission to run that specific system command. Any other app which also needs to run ping will also have to ask for permission to run ping, regardless of whether other apps have been granted the same permission. This should be persistent through system upgrades (but perhaps not through upgrades of the app itself – arguments could be made both ways there).

This would make it much easier for the users installing apps that depend on certain system commands and upgrading the system afterwards, and it would make a slight improvement to the security when permissions are app specific.

Nice idea - we will think about it. The problem is that we need to inspect for security each module even more precisely. This is not that easy as you can make a lot of bad things with bash scripts.

Indeed allowing a checkbox might be an option, but if this checkbox is set from Z-Way itself, any module can set it too (this is because the UI uses the API that can be altered by the module). So this is absolutelly unsecure.

Indeed allowing a checkbox might be an option, but if this checkbox is set from Z-Way itself, any module can set it too (this is because the UI uses the API that can be altered by the module). So this is absolutelly unsecure.

I see. I didn't think about that. Would be great if there was a way around that hurdle, though.