Arch Linux

cable

Member

Registered: 2015-05-14

Posts: 5

Process substitution, FIFO, and password security

So I'm trying to eliminate storing plain-text passwords in configuration files that have blocks that look like so:

username = USERNAME
password = PASSWORD

Applications that use such configurations (like mopidy) don't have the ability to invoke password retrieval commands like pass.

The solution I thought up was to use m4 and run something like

someApplication --config <(m4 configFile)

where "configFile" reads

define(`USERNAME',`esyscmd(pass ls someService | grep -Po "(?<=─ ).*")') dnl
define(`PASSWORD',`esyscmd(pass someService/USERNAME)') dnl
username = USERNAME 
password = PASSWORD

The first two lines merely state that "USERNAME" and "PASSWORD" will be replaced with the outputs of the command

pass

(the "grep" is just to clean up the output of the "pass" command).

But that didn't work because "someApplication" (or "m4") requires privileged access to "/proc/fd/*". After reading up on process substitution, I learned about "mkfifo" and now use this:

tmpFile=/tmp/credentials.fifo 
mkfifo $tmpfile 
m4 configFile > $tmpFile & 
someApplication --config $tmpFile

This seems to work, i.e. no plain text passwords seem to be stored anywhere. But is that really the case? Is this solution safe?

seth

Member

Registered: 2012-09-03

Posts: 50,957

Re: Process substitution, FIFO, and password security

The m4 output can be read by anyone and anything that has access to /tmp/credentials.fifo until something reads it.
Then its gone.

If someApplication is fine with that, you could make it open & read the fifo before redirecting the m4 script into it.

nb that some PW managers allow unencrypted read of the vault by anyone and anything once it's opened which is maybe the bigger issue here?

---

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

cable

Member

Registered: 2015-05-14

Posts: 5

Re: Process substitution, FIFO, and password security

The m4 output can be read by anyone and anything that has access to /tmp/credentials.fifo until something reads it.
Then its gone.

Indeed. Therein lies the weakness.

If someApplication is fine with that, you could make it open & read the fifo before redirecting the m4 script into it.

Unfortunately, someApplication is not.
It would be great if process substitution worked, but it doesn't.

nb that some PW managers allow unencrypted read of the vault by anyone and anything once it's opened which is maybe the bigger issue here?

It's crazy that PW managers like that are still around. The one I use (pass), doesn't work that way.