Save passwords in scripts

[Florian Lindner]

Paul Rubin wrote:

> Florian Lindner <Florian.Lindner at xgm.de> writes:
>> I've a scripts that allows limited manipulation of a database to users.
>> This script of course needs to save a password for the database
>> connection. The users, on the other hand need read permission on the
>> script in order to execute it but should not be able to read out the
>> password. What is the common way to solve this problem?
>> 
>> My current way is to allow the users to execute the script with sudo
>> while not having read permission when acting as a ordinary user. But I
>> don't like this solutions and consider it very ugly.
> 
> There's not a one-size-fits-all answer.  A bunch of possibilities:
> 
> - Just have execute permission on the script, not read permission

This does not work. In ordner to execute the interpreter have to read the
script.

florian at horus ~/python $ ./account.py
/usr/bin/python: can't open file './account.py'

Or you know a way it works?
 
> - If the database server and client are running on the same machine,
> use a unix-domain socket instead of a tcp socket, and modify the
> server to check that only a specific uid is running the client (you
> can do this check with an ancillary message on the socket).  Then use
> sudo to get the client to run as that user.  You can then leave read
> permission enabled on the script.

This a bit overkill for my needs.
 
> - sort of similar: have a separate process running that knows the
> password (administrator enters it at startup time).  That process
> listens on a unix socket and checks the ID of the client.  It reveals
> the password to authorized clients, i.e. your readable script running
> under sudo.  This keeps the password from ever being stored on disk.
> 
> - Modify the script itself to run as a long-running service instead of
> as something that gets started and restarted all the time.  Have an
> admin start it and type the password into it at startup time.  Users
> then connect to it (maybe with a web browser) and send it commands.
> 
> - Move the user operations from the script to server side database
> procedures that do their own validity checking.  Then you don't need a
> password.

I'll evaluate the 3 ideas above further.

> - Run the script on a machine where users can't run arbitrary programs
> other than the script.  Set up the db server to not accept any
> connections other than from that machine.

Not possible here.

Thanks for your suggestions,

Florian