Paul Rubin wrote: > Florian Lindner <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED] ~/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 -- http://mail.python.org/mailman/listinfo/python-list
