Save passwords in scripts
Florian.Lindner at xgm.de
Tue Mar 22 01:36:28 CET 2005
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
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
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,
More information about the Python-list