E.B.
2015-Mar-11 05:52 UTC
Sieve security: Any way to protect credentials used in extprograms?
I need to connect to a database in a script called using Sieve extprograms plugin. When delivering mail, Sieve is running as the mail recipient user, which means any files, either the sieve script or the extprograms it invokes, are run under that user's permissions. What would be a way to hide the database credentials in a more restricted file? I can think of... * Store the credentials in the database itself, return them from a DICT lookup that is fed to the sieve script. The credentials would have to be duplicated for every user record in the database. * Somehow put the value in the Sieve environment, but I'm not sure how to get a value into the environment (just return it in a userdb lookup?) and then how to get at that value once I'm executing the sieve script (can I retrieve it with the "environment" extension?) Are there better ways? [Of course, if I could do more elaborate things like call a stored procedure from Dovecot DICT then I could avoid this situation]
Stephan Bosch
2015-Mar-11 21:54 UTC
Sieve security: Any way to protect credentials used in extprograms?
On 3/11/2015 6:52 AM, E.B. wrote:> I need to connect to a database in a script called using Sieve > extprograms plugin. When delivering mail, Sieve is running > as the mail recipient user, which means any files, either the > sieve script or the extprograms it invokes, are run under that > user's permissions. > > What would be a way to hide the database credentials in a > more restricted file? I can think of... > > * Store the credentials in the database itself, return them > from a DICT lookup that is fed to the sieve script. The > credentials would have to be duplicated for every user > record in the database. > > * Somehow put the value in the Sieve environment, > but I'm not sure how to get a value into the environment > (just return it in a userdb lookup?) and then how to get > at that value once I'm executing the sieve script (can I > retrieve it with the "environment" extension?) > > Are there better ways?I would put that script invocation in a script service running as a different user. That should also answer much of your other e-mail. Regards, Stephan.