Thread: pg_hba.conf editing question
I am working with the pgAdmin git source and I am having trouble understanding the adminpack functions being used. In the file pgadmin/frm/frmHbaConfig.cpp, the pg_hba.conf edit form constructor appears to get the absolute path to the configuration file and stores this value in "serverFileName" ("SHOW hba_file"). The value is then used to few lines down in a call to "SELECT pg_file_read(...)". Net Search suggests that pg_file_read can be used to access files in the pg data/log directories only. Experimenting on my localhost, any attempt to use a "../" or and absolute path results in an error. What I'm having a problem understanding is how the pg_file_read function can work in this context. I can access files in the data directory nicely, but emulating the queries being used in the pgAdmin code will not work. What magic was built into the code to get around the absolute path security? Regards, Scott
2014-07-19 18:11 GMT+02:00 Scott Furry <scott.wl.furry@gmail.com>:
I am working with the pgAdmin git source and I am having trouble understanding the adminpack functions being used.
In the file pgadmin/frm/frmHbaConfig.cpp, the pg_hba.conf edit form constructor appears to get the absolute path to the configuration file and stores this value in "serverFileName" ("SHOW hba_file"). The value is then used to few lines down in a call to "SELECT pg_file_read(...)".
Net Search suggests that pg_file_read can be used to access files in the pg data/log directories only. Experimenting on my localhost, any attempt to use a "../" or and absolute path results in an error.
What I'm having a problem understanding is how the pg_file_read function can work in this context. I can access files in the data directory nicely, but emulating the queries being used in the pgAdmin code will not work. What magic was built into the code to get around the absolute path security?
No magic. pg_file_read() calls pg_read_file. Here is the main comment of this function:
/*¬
* Convert a "text" filename argument to C string, and check it's allowable.¬
*¬
* Filename may be absolute or relative to the DataDir, but we only allow¬
* absolute paths that match DataDir or Log_directory.¬
*/¬
/*¬
* Convert a "text" filename argument to C string, and check it's allowable.¬
*¬
* Filename may be absolute or relative to the DataDir, but we only allow¬
* absolute paths that match DataDir or Log_directory.¬
*/¬
So the path may be absolute but, in such a case, it must contain the data directory.
--
On 20/07/14 02:45 PM, Guillaume Lelarge wrote: > 2014-07-19 18:11 GMT+02:00 Scott Furry <scott.wl.furry@gmail.com > <mailto:scott.wl.furry@gmail.com>>: > > I am working with the pgAdmin git source and I am having trouble > understanding the adminpack functions being used. > > In the file pgadmin/frm/frmHbaConfig.cpp, the pg_hba.conf edit > form constructor appears to get the absolute path to the > configuration file and stores this value in "serverFileName" > ("SHOW hba_file"). The value is then used to few lines down in a > call to "SELECT pg_file_read(...)". > > Net Search suggests that pg_file_read can be used to access files > in the pg data/log directories only. Experimenting on my > localhost, any attempt to use a "../" or and absolute path results > in an error. > > What I'm having a problem understanding is how the pg_file_read > function can work in this context. I can access files in the data > directory nicely, but emulating the queries being used in the > pgAdmin code will not work. What magic was built into the code to > get around the absolute path security? > > > No magic. pg_file_read() calls pg_read_file. Here is the main comment > of this function: > > /*¬ > * Convert a "text" filename argument to C string, and check it's > allowable.¬ > *¬ > * Filename may be absolute or relative to the DataDir, but we only allow¬ > * absolute paths that match DataDir or Log_directory.¬ > */¬ > > So the path may be absolute but, in such a case, it must contain the > data directory. What about the case of a linux-base system. There was another message on the pgAdmin list mentioning that pg_file_read did not work on Debian. I used pgAdmin on a Windows system to edit the pg_hba.conf file. No problems, but emulating that behaviour on linux systems by entering the SQL commands fails. I'm using the postgres account and the "SELECT pg_file_read" command fails if I try to take into account the data directory. Using: SELECT * from pg_read_file('../../../../../etc/postgresql/9.3/main/pg_hba.conf'); will return the error: ERROR: path must be in or below the current directory Yet this sequence of commands works for pgAdmin? This is why I'm asking here if there was some special setup made when calling the config file editing. Thanks for the help. Scott
2014-07-20 23:15 GMT+02:00 Scott Furry <scott.wl.furry@gmail.com>:
On 20/07/14 02:45 PM, Guillaume Lelarge wrote:2014-07-19 18:11 GMT+02:00 Scott Furry <scott.wl.furry@gmail.com <mailto:scott.wl.furry@gmail.com>>:What about the case of a linux-base system. There was another message on the pgAdmin list mentioning that pg_file_read did not work on Debian. I used pgAdmin on a Windows system to edit the pg_hba.conf file. No problems, but emulating that behaviour on linux systems by entering the SQL commands fails.
I am working with the pgAdmin git source and I am having trouble
understanding the adminpack functions being used.
In the file pgadmin/frm/frmHbaConfig.cpp, the pg_hba.conf edit
form constructor appears to get the absolute path to the
configuration file and stores this value in "serverFileName"
("SHOW hba_file"). The value is then used to few lines down in a
call to "SELECT pg_file_read(...)".
Net Search suggests that pg_file_read can be used to access files
in the pg data/log directories only. Experimenting on my
localhost, any attempt to use a "../" or and absolute path results
in an error.
What I'm having a problem understanding is how the pg_file_read
function can work in this context. I can access files in the data
directory nicely, but emulating the queries being used in the
pgAdmin code will not work. What magic was built into the code to
get around the absolute path security?
No magic. pg_file_read() calls pg_read_file. Here is the main comment of this function:
/*¬
* Convert a "text" filename argument to C string, and check it's allowable.¬
*¬
* Filename may be absolute or relative to the DataDir, but we only allow¬
* absolute paths that match DataDir or Log_directory.¬
*/¬
So the path may be absolute but, in such a case, it must contain the data directory.
I'm using the postgres account and the "SELECT pg_file_read" command fails if I try to take into account the data directory.
Using:
SELECT * from pg_read_file('../../../../../etc/postgresql/9.3/main/pg_hba.conf');
will return the error:
ERROR: path must be in or below the current directory
Yet this sequence of commands works for pgAdmin?
I'm pretty sure it doesn't.
This is why I'm asking here if there was some special setup made when calling the config file editing.
Nope, no special setup.
--
On 20/07/14 03:20 PM, Guillaume Lelarge wrote: > 2014-07-20 23:15 GMT+02:00 Scott Furry <scott.wl.furry@gmail.com > <mailto:scott.wl.furry@gmail.com>>: > > > On 20/07/14 02:45 PM, Guillaume Lelarge wrote: > > 2014-07-19 18:11 GMT+02:00 Scott Furry > <scott.wl.furry@gmail.com <mailto:scott.wl.furry@gmail.com> > <mailto:scott.wl.furry@gmail.com > <mailto:scott.wl.furry@gmail.com>>>: > In the file pgadmin/frm/frmHbaConfig.cpp, the pg_hba.conf edit > form constructor appears to get the absolute path to the > configuration file and stores this value in "serverFileName" > ("SHOW hba_file"). The value is then used to few lines > down in a > call to "SELECT pg_file_read(...)". > No magic. pg_file_read() calls pg_read_file. Here is the main > comment of this function: > > So the path may be absolute but, in such a case, it must > contain the data directory. > > > I'm using the postgres account and the "SELECT pg_file_read" > command fails if I try to take into account the data directory. > Using: > SELECT * from > pg_read_file('../../../../../etc/postgresql/9.3/main/pg_hba.conf'); > will return the error: > ERROR: path must be in or below the current directory > > Yet this sequence of commands works for pgAdmin? > > I'm pretty sure it doesn't. Apologies...I wasn't paying attention to what I was posting. I'm just trying to understand how the pg_hba.conf file can be read in pgAdmin. I've tried variations to emulate the SQL commands used in pgAdmin to no avail. I'm using postgres db and postgres account to connect with the localhost via psql. Absolute path...Relative path...nothing seems to work. Yet, pgAdmin (in the HbaConfig.cpp file) can grab the absolute path of a config file ("SHOW hba_file") then call "SELECT pg_file_read()" and doesn't return an error. If there is no special setup, then how can this fail on the command line yet work in pgAdmin? What obvious thing am I missing here? Scott
On 20/07/14 03:40 PM, Scott Furry wrote: > I'm just trying to understand how the pg_hba.conf file can be read in > pgAdmin. > > I've tried variations to emulate the SQL commands used in pgAdmin to > no avail. I'm using postgres db and postgres account to connect with > the localhost via psql. Absolute path...Relative path...nothing seems > to work. Yet, pgAdmin (in the HbaConfig.cpp file) can grab the > absolute path of a config file ("SHOW hba_file") then call "SELECT > pg_file_read()" and doesn't return an error. > > If there is no special setup, then how can this fail on the command > line yet work in pgAdmin? > What obvious thing am I missing here? The obvious thing that I was missing was that Debian does really weird things with its PostgreSQL packaging. For some reason, the configuration files are stored in a folder below /etc/postgresql, well outside the data directory. I had seen a message like this in searching this problem, but it was dated a couple of years ago. Sad the problem still exists. I can confirm (at least on Arch and Win7) the functionality for server configuration files works just fine, as-is and out-of-the-box. Its debian that has the problem. Sorry for the noise. Scott
On 21/07/14 08:58 AM, Christoph Berg wrote: > That split conf-data setup is supported by PostgreSQL, so it's not > Debian to blame. I think it is a bug (or missing feature) that > pg_read_file doesn't let you read files in the conf directory. > > What probably works is if you create a symlink in the data directory > to /etc/postgresql for pg_hba.conf and postgresql.conf. > Its great that PostgreSQL supports split configuration/data directory. In one of the message threads I found, a dev from PostgreSQL mentioned that the functions in the adminpack were written to prevent using paths out of the log/data directory expressly for security reasons. And I understand that rationale. It makes sense. I couldn't fathom how pgAdmin built in a means to alter configuration files when it didn't work in one instance. I think it makes it difficult for pgAdmin devs to maintain consistency across platforms when one linux distribution does something "a little different" that isn't done elsewhere AFAIK. Maybe as part of the Debian packaging those symlinks should be created/installed as part of the server package? But that's for the Debian dev's to sort out and discuss on the Debian forums. Scott
<p dir="ltr">Le 21 juil. 2014 17:34, "Scott Furry" <<a href="mailto:scott.wl.furry@gmail.com">scott.wl.furry@gmail.com</a>>a écrit :<br /> ><br /> ><br /> > On 21/07/1408:58 AM, Christoph Berg wrote:<br /> >><br /> >> That split conf-data setup is supported by PostgreSQL,so it's not<br /> >> Debian to blame. I think it is a bug (or missing feature) that<br /> >> pg_read_filedoesn't let you read files in the conf directory.<br /> >><br /> >> What probably works is if youcreate a symlink in the data directory<br /> >> to /etc/postgresql for pg_hba.conf and postgresql.conf.<br /> >><br/> > Its great that PostgreSQL supports split configuration/data directory.<br /> ><br /> > In one ofthe message threads I found, a dev from PostgreSQL mentioned that the functions in the adminpack were written to preventusing paths out of the log/data directory expressly for security reasons. And I understand that rationale. It makessense.<br /> ><br /> > I couldn't fathom how pgAdmin built in a means to alter configuration files when it didn'twork in one instance. I think it makes it difficult for pgAdmin devs to maintain consistency across platforms whenone linux distribution does something "a little different" that isn't done elsewhere AFAIK.<br /> ><br /> > Maybeas part of the Debian packaging those symlinks should be created/installed as part of the server package?<br /> >But that's for the Debian dev's to sort out and discuss on the Debian forums.<br /> ><p dir="ltr">Well, truly honestly,I've never used and will never use the config editor from PgAdmin. It's not good enough to be useful and practical.<pdir="ltr">I'd trust more a complete rewrite with the 9.4 ALTER SYSTEM statement.<p dir="ltr">Of course, thisis just my point of view.