Previously, a plugin would always run as the User that is calling it. This was simple and secure, but proved to be an issue for some plugins that required access to different areas of the system, as they wouldn't have sufficient privileges. A new default directadmin.conf option will be present, and this is the internal default for that option: plugins_allowed_run_as=1 so if you do not wish to allow plugins to set different User values to run as, set your directadmin.conf to have: plugins_allowed_run_as=0 *** SECURITY IS ENTIRELY UP TO YOU, the plugin designer *** As for plugin coders, if you wish to set any level to run as a specific user, you'd add any of these options to your plugin.conf file: admin_run_as=user reseller_run_as=user user_run_as=user where you can set "user" to any value you wish, as long as it's not uid=0. Meaning, DA will actively do a check the /etc/passwd file for the uid, to ensure you didn't create another non-root User with uid=0. For any line that is not there, DA will run as the User that is logged in to DA, just like plugins already do. This means that existing plugins will still work fine. A side-benefit of running a plugin as one account (which nobody else has access to), is you can much more easily setup an suid binary with 4750 root:user, so that no other account can call it, making security much easier, while still allowing root access via the suid wrapper. Other benefits would be a common user for reading or writing a plugin data file, as needed. However, if you set a level to run as that User, it also means that the plugin, at that level, will no longer be running as the account that's logged in... so this feature wouldn't apply to any User Level plugins that need to write to /home/username for the current account. NOTE about environmental variables: New variable: RUNNING_AS will be the value that the script is running as. As well: USERNAME USER will remain unchanged as the normal values of the current account, and they will not reflect the username that the script is running as. If you need the Admin Level account have access to a specific system account, as well as another account, or it's own account, you can blend the plugin levels to have different Users. For example: admin_run_as=pluginuser user_run_as=pluginuser If you want Admin and Users to have access to files created by the plugin, but the the Admin could call CMD_PLUGINS_RESELLER to be running the plugin as themselves, for other local data under /home/admin, for example. Of course, you'd want the Reseller Level plugin to double check that the current account is indeed an Admin, or you might have some confused Resellers. In any case, the mix and match method just gives you more options to run the plugin in different ways. Try to leave the more dangerous levels of access to Admin accounts only, in case you have a code bug, giving Resellers or Users access to things.