Re: WAL file location
От | Bruce Momjian |
---|---|
Тема | Re: WAL file location |
Дата | |
Msg-id | 200207301837.g6UIbCn02155@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: WAL file location (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
In my logic, we have PGDATA environment variable for the server only so the server can find the /data directory. After that, everything should be in /data. I see no reason to make it an environment variable. In fact, a file in /data should be able to track the xlog directory a lot better than an evironment variable will. --------------------------------------------------------------------------- Tom Lane wrote: > Andrew Sullivan <andrew@libertyrms.info> writes: > > On Tue, Jul 30, 2002 at 02:05:57PM -0400, Tom Lane wrote: > >> If we add more environment-variable-dependent mechanisms to allow more > >> different things to be done, we increase substantially the odds of > >> creating an exploitable security hole. > > > Ok, true enough, but I'm not sure that a config file or any other > > such mechanism is any safer. As Lamar Owen said, anyone who can > > poison the postgres user's environment can likely do evil things to > > postgresql.conf as well. > > Who said anything about poisoning the environment? My point was that > there will be strings in the environment that were put there perfectly > legitimately, but could still serve as an attack vehicle. > > The weakness of the existing database-locations-are-environment-variables > feature is really that the attacker gets to choose which environment > variable gets used, and so he can use a variable intended to serve > purpose A for some other purpose B. If A and B are sufficiently > different then you got trouble --- and since we are talking about a > purpose B that involves writing on something, there's definitely a risk. > > A mechanism based only on a fixed environment variable name doesn't > create the sort of threat I'm contemplating. For example, if the > postmaster always and only looked at $PGXLOG to find the xlog then > you'd not have this type of risk. But Thomas said he was basing the > feature on database locations, and in the absence of seeing the code > I don't know if he's creating a security hole or not. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: