On Wed, Nov 13, 2019 at 3:23 PM Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > I think it would be beneficial to explain why shared object is more > secure than an OS command. Perhaps it's common knowledge, but it's not > quite obvious to me.
External command args can be viewed by other OS users (not just the postgres user). For non-sensitive arguments (ex: WAL filename?) that's not an issue but if you plan on passing in something potentially secret value from the backend to the external OS command, that value would be exposed: Terminal 1 (run a command as some other user): $ sudo -u nobody sleep 5 Terminal 2 (view command args as a different non-super user): $ ps -u nobody -o args COMMAND sleep 5 A shared library would not have this problem as the backend directly executes the library in the same process. Has the idea of using environment variables (rather than command line args) for external commands been brought up before? I couldn't find anything in the mailing list archives. Environment variables have the advantage of only being readable by the process owner and super user. They also naturally have a "name" and do not have escaping or quoting issues. For example, archive_command %p could be exposed as PG_ARG_ARCHIVE_PATH and %f could be exposed as PG_ARG_ARCHIVE_FILENAME. Then you could have a script use them via: #!/usr/bin/env bash set -euo pipefail main () { local archive_dir="/path/to/archive_dir/" local archive_file="${archive_dir}${PG_ARG_ARCHIVE_FILENAME}" test ! -f "${archive_file}" && cp -- "${PG_ARG_ARCHIVE_PATH}" "${archive_file}" } main "$@" It's not particularly useful for that basic archive case but if there's something like PG_ARG_SUPER_SECRET then the executed command could receive that value without it being exposed. That'd be useful for something like a callout to an external KMS (key management system). Nothing stops something like this with being used in tandem with string substitution to create the full commands. That'd give backwards compatibility too. The main limitation compared to a shared library is that you'd still have to explicitly pick and name the exposed argument environment variables (i.e. like picking the set of %? substitutions). If there's a generic shared-library-for-external-commands approach then there could be a built-in library that provides this type of "expose as env vars" functionality. Regards, -- Sehrope Sarkuni Founder & CEO | JackDB, Inc. | https://www.jackdb.com/