I have a program that updates a DBM file owned by a service account to cache the result of an expensive query.

We now need user accounts to be able to run this program to query and cache. There is no risk of misuse by users and concurrency is not an issue, but we do want to prevent accidental deletion of the DBM, for example. A theoretical concern exists if an intruder obtained access to the user's shell account, the setuid approach might provide a vector to execute code as the service account that might not otherwise exist.

We have thought of three approaches to permitting access:

• Use setuid with the current DBM cache service.
• Have the service account run a webserver (e.g., Mojolicious) to update the DBM cache.
• Replace software with mysql/pg with its own authentication.

The setuid approach is somehow preceived as more risky by IT as it is a well-known risk. My own take is that the webserver opens up risks that are not obvious (and probably exposes some of the same risks as setuid -- namely code may be executed in the name of the service account if the attacker controls the code that updates the DBM). The database approach would be new for us -- and thus implies additional maintenance, infrastructure, and potentially, new authentication surfaces not already in place. However, the database is a well-understood security problem but we perhaps lack in-house experience to approach it correctly.

Wise Monks, my problem cannot be unique. Is there another approach not considered here? What is the best way?