On Thu, Nov 21, 2013 at 9:54 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Thu, Nov 21, 2013 at 8:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Amit Kapila <amit.kapil...@gmail.com> writes: >>> Here what I have in mind is that: >> >> Why would you make psql behave differently from our other command-line >> clients? > > No, psql should not behave different from other clients. Sorry, I > was under assumption that for other programs we will not take backend > executable > path. > One other thing which is not clear to me is that how by calling > some special/new API we can ensure that the path provided by user is > a valid path, are we going to validate file given in > 'standalone_backend' switch in some way?
Here, do we mean that if user specifies special switch, then psql/pg_dump will call new API (eg. PQstartSingleUser(dsn)) which will use postgres from same bin directory they are in, rather than using from standalone_backend. Can we consider this as a way to proceed for this patch? On a side note, today while reading what other software's does to protect them from such a security threat, I came across this link (http://osxbook.com/book/bonus/chapter7/binaryprotection/index.html) which suggests to have encrypted binaries. The use for encrypted binaries is somewhat similar to what we discussed as a security threat in this mail thread. Some text from link which made me think that this is relevant. For example, "one could turn the requirement around and say that a given system must not run any binaries unless they are from a certain source (or set of sources). This could be used to create an admission-control mechanism for executables, which in turn could be used in defending against malware. In a draconian managed environment, it might be desired to limit program execution on managed systems to a predefined set of programs—nothing else will execute." With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers