I am working on a bash script which logs into a database via a command-line program.
I need to provide the administrator password to the database command line tool, and am not sure how to properly hide the value.
The command line program allows you to set the password in a shell variable to avoid putting it on the command line, or as part of a HERE document.
However, how do I get it into the shell variable without it being exposed in a filesystem?

have you searched before posting?
https://duckduckgo.com/?q=linux+Hidi...rds+in+scripts
looks like you're not the first one to ask this question.

Yes, but these answers don't fit the bill.
All of them still require the password to be in a file in the filesystem.

Is the script being called interactively (i.e. by a user) or in an automated way (e.g. by a cronjob).

In the first case you could set the variable containing the password even before calling the script. Or you could prompt for it using the read command.

In the second case it would be more difficult and possible answers would depend on your requirements, so maybe you could desribe those a bit more. (I am assuming your question has a security-related motivation, so please describe the attack scenario vs. legitimate use of the script).
Maybe it would solve your problem if the script was called from a cronjob running on another (more trusted) machine via ssh which could provide the password? (In that case make sure it is not showing up in ssh server logs of the target machine!)

The script would be called via automation (most likely cron).
The requirements are based on auditing policy which does not allow us to store any passwords in the filesystem.
We do not (currently) have any more trusted machine, as if I could reach it from the first host it's just as open to being hacked.
Getting an 'exception' to the policy is always an option, but im being asked to make sure there are no other alternatives before proceeding with an exception request.

You should (might?) be able to set permissions on such a file so that only the user running the cron and root could see it.

Well I'm not sure what your options are then. If you can't type it in interactively and you can't store it on the filesystem, where do you plan for the script to access the password? Whether it's plain-text in the script, or in the cron tab, or on another machine, or encrypted in a file with the password for that file located in plain-text in one of the above-mentioned locations...you're still storing the password in the filesystem, which is against policy. I think the only way around this is to get an exception to the policy. In doing so there are a few options, such as restricting permissions, putting it on a tmpfs/ramfs filesystem that gets wiped when the machine is power-cycled, etc.

That's the rub. Ive heard of some type of key server type of thing, but don't know anything about them.
Supposedly you can checkout the password dynamically, in memory, but I don't know what they are called or anything else.

How about you write a program to run on your computer and do the actual database read/writes, not in shell script but in some language where you can employ binary code obfuscation and which can access the database securely using the password calculated from its own internals. The program will also check to see if any of its own code has been modified at any point. The program would have *very specific and restricted* login permissions to the database and transactions it could undertake. Naturally the source code would be nowhere near the machine in question.

A hacker with root access to your computer and reasonable skills will be able to do anything they want, effectively, but if you make it more difficult to achieve their task then they *might* think about finding a softer target.

What is the logging in for? Is it something that can be done by other means? With a middle man that runs on the database server that generates results to a file, or inputs changes from a file. With more acceptable scp or sftp methods via key pairs?

From a certain point of view, ALL passwords are on the disk / filesystem. Baring the rare exception of hardware that handles that function. Even if it's in the program it's on a filesystem. You can hide it logically by joining multiple chunks from non-adjacent locations, or convert it from hex or binary strings. But it's still ON the filesystem from an overly technical point of view.

The app server is the middle man in this case. The application needs to login to the database to get access to data.
While it's possible to store the password encrypted, the decryption process itself requires a password, so that's a catch-22.

I vote for the exception to the policy. Implemented in a responsible way. The thing is: The application is on the machine. Whatever you implement: there will always be a risk that someone who "hacked into the machine" will be able to intercept/reverse engineer/reproduce or otherwise compromise the authentication process.

The time you spent on this question would be better spent thinking about how to implement general hardening for the machine to prevent it from being compromised in the first place.
Oh, just to make sure it has been said: for your app server you'll want to use login credentials of a database user that only has read access if that's all your application needs.

1 members found this post helpful.

I do use export scripts in a root-owned crons.
stored in /root/ and 700
But...<wait for it>
as suggested, it is a database "user" with the least amount of privs necessary.

It is the exception and not the rule.

Just sayin'

The "user" is the database account itself. The scripts are all of administrative nature, auditing, code release, monitoring and ETL.
Ill probably have to go with the exception, but was trying to cover my bases and see if there was some other tool/utility or methodology which could work that I wasn't aware of.

The ole' CRON job needs password to run scenario -
color me stupid but it seems to me if a cron job needed a password to run then it needs to be ran on the Administrate (root) side where no password is needed. Then only one that is root or has that password can fiddle with it. fingers then would be known where to point if something happens that is directly related to that script (job) running.