OK, let's go with something that is purely log stuff and we can revisit
in 7.6. Ultimately I think we want postgresql.conf and pg_hba.conf to
be controllable perhaps at the SQL level rather than the function call
level so we need to scope the entire design for 7.6. There is certainly
need for re
OK, let's go with something that is purely log file stuff.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Agreed it should be relative to the log directory, which may or not be
> > under PGDATA, and do
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > One issue is that the log files might be in /var/log with other server
> > logs.
>
> Probably not; it seems unlikely that the postgres user would have write
> permission on /var/log, as it would have to have to do log rotation in
> su
Bruce Momjian <[EMAIL PROTECTED]> writes:
> One issue is that the log files might be in /var/log with other server
> logs.
Probably not; it seems unlikely that the postgres user would have write
permission on /var/log, as it would have to have to do log rotation in
such a case. I'd expect anyone
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Agreed it should be relative to the log directory, which may or not be
> > under PGDATA, and don't let them go up above it. Is there any downside
> > to allowing absolute reads as well because COPY can already read
> > absolute files.
Maybe we could allow unlink or rename if access() shows we own the file
or something.
---
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Agreed it should be relative to the log dir
Bruce Momjian wrote:
As a super-user, could an attacker load a server-side language and
access the backend environment variable PGDATA.
plperl won't do it, but plperlu will (as expected I guess). But the
superuser will have to jump through some explicit hoops in order to get
there, which is
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
>
> >As a super-user, could an attacker load a server-side language and
> >access the backend environment variable PGDATA.
> >
> >
>
> plperl won't do it, but plperlu will (as expected I guess). But the
> superuser will have to jump through
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Agreed it should be relative to the log directory, which may or not be
> under PGDATA, and don't let them go up above it. Is there any downside
> to allowing absolute reads as well because COPY can already read
> absolute files.
Perhaps not from a secur
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>> Thinking we have security because they can't guess
>>> pgdata seems like security through obscurity to me.
>>
>> Sure, but it's still a useful roadblock to throw in an attacker's way.
> As
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Thinking we have security because they can't guess
> > pgdata seems like security through obscurity to me.
>
> Sure, but it's still a useful roadblock to throw in an attacker's way.
>
> I spent many years doing computer security stuf
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Andreas didn't ask for a full file API. I suggested it because we were
> > already going to have some of the functionality. If rename/unlink are
> > new problems, we can skip them and just add what Andreas needs right
> > now.
>
> G
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Thinking we have security because they can't guess
> pgdata seems like security through obscurity to me.
Sure, but it's still a useful roadblock to throw in an attacker's way.
I spent many years doing computer security stuff, and one thing I
learned is
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Andreas didn't ask for a full file API. I suggested it because we were
> already going to have some of the functionality. If rename/unlink are
> new problems, we can skip them and just add what Andreas needs right
> now.
Given the security worries that
Andreas didn't ask for a full file API. I suggested it because we were
already going to have some of the functionality. If rename/unlink are
new problems, we can skip them and just add what Andreas needs right
now.
---
And
Tom Lane wrote:
Stephan Szabo <[EMAIL PROTECTED]> writes:
On Fri, 23 Jul 2004, Andreas Pflug wrote:
What I'd like is
SELECT pg_file_unlink('postgresql.conf.bak');
SELECT pg_file_write('postgresql.conf.tmp', 'listen_addresses=...');
SELECT pg_file_rename('postgresql.conf.tmp', 'postgresql.c
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I'm pretty much against allowing configuration editing from remote
> >> altogether.
>
> > Why can't they just use COPY to replace the contents of pg_hba.conf now?
>
> If you've write-protected it, that doesn't wo
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> As for the analogy to COPY, the addition of unlink/rename to a hacker's
>> tool set renders the situation far more dangerous than if he only has
>> write. Write will not allow him to hack write-protected files, but he
>> might be able
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> As for the analogy to COPY, the addition of unlink/rename to a hacker's
> >> tool set renders the situation far more dangerous than if he only has
> >> write. Write will not allow him to hack write-protected files
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm pretty much against allowing configuration editing from remote
>> altogether.
> Why can't they just use COPY to replace the contents of pg_hba.conf now?
If you've write-protected it, that doesn't work.
Also, COPY insists on an ab
Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Fri, 23 Jul 2004, Andreas Pflug wrote:
> >> What I'd like is
> >>
> >> SELECT pg_file_unlink('postgresql.conf.bak');
> >> SELECT pg_file_write('postgresql.conf.tmp', 'listen_addresses=...');
> >> SELECT pg_file_rename('postgresql.c
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Fri, 23 Jul 2004, Andreas Pflug wrote:
>> What I'd like is
>>
>> SELECT pg_file_unlink('postgresql.conf.bak');
>> SELECT pg_file_write('postgresql.conf.tmp', 'listen_addresses=...');
>> SELECT pg_file_rename('postgresql.conf.tmp', 'postgresql.conf',
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Also, while I'm aware that a superuser can persuade the backend to write
> >> on anything, it doesn't follow that we should invent pg_file_write(),
> >> pg_file_rename(), or pg_file_unlink().
>
> > I think the ana
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Also, while I'm aware that a superuser can persuade the backend to write
>> on anything, it doesn't follow that we should invent pg_file_write(),
>> pg_file_rename(), or pg_file_unlink().
> I think the analogy is locking one door but l
On Fri, 23 Jul 2004, Andreas Pflug wrote:
> > What we probably want instead is a separate
> > redirect_stderr_to_files boolean (I'm sure a better name could be
> > thought of).
> >
> > Also, while I'm aware that a superuser can persuade the backend to write
> > on anything, it doesn't follow that
Tom Lane wrote:
> Also, while I'm aware that a superuser can persuade the backend to write
> on anything, it doesn't follow that we should invent pg_file_write(),
> pg_file_rename(), or pg_file_unlink(). Those are not needed for the
> originally intended purpose of this patch and I think that they
Tom Lane wrote:
Bruce Momjian wrote:
Are we done?
Nope, the syslogger part of this is still a mess. I don't want any
pg_logfile_rotate() function in there at all: its presence is a hangover
from a different design philosophy.
No. As I mentioned earlier, there might be cases when a superuser wants
Bruce Momjian wrote:
> Are we done?
Nope, the syslogger part of this is still a mess. I don't want any
pg_logfile_rotate() function in there at all: its presence is a hangover
from a different design philosophy. Nor pg_reload_conf(); where did
that come from? (Hint: if you can edit postgresql.c
Bruce Momjian wrote:
Are we done? Seems pg_file_stat() works fine. Do we need other
adjustments?
Here are the documentation changes.
Regards,
Andreas
Index: catalogs.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/ca
Bruce Momjian wrote:
Here is what you can do:
SELECT filename,
(SELECT file_len FROM pg_file_stat(filename)),
(SELECT file_ctime FROM pg_file_stat(filename)),
(SELECT file_mtime FROM pg_file_stat(filename)),
(SELECT file_atime FROM pg_file_stat(filename))
FROM pg_dir_ls('/etc') AS
Andreas Pflug wrote:
> > or something like that. However, I don't think you can have a function
> > call returning multiple values in the target list, and I can't figure
> > out how to pass an argument to the function if it is in the target list.
> > Ideas?
>
> I thought of
> SELECT filename, len
Bruce Momjian wrote:
I now replaced pg_logfile_length, instead pg_logfile_stat(text) will
return a record (len int8, ctime timestamp, atime timestamp, mtime
timestamp, isdir bool).
You mean pg_file_stat(text), right?
Of course.
For convenience, I'd like to have the function
CREATE FUNCTION pg
Andreas Pflug wrote:
> Bruce Momjian wrote:
> > Andreas Pflug wrote:
> >
>
> >
> >
> > OK, new idea. Forget about modifying pg_dir_ls(). Instead add
> > pg_file_stat the returns the file size, times. You can then easily use
> > that for file size and times. Also, if you want, add an is_dir
Bruce Momjian wrote:
Andreas Pflug wrote:
OK, new idea. Forget about modifying pg_dir_ls(). Instead add
pg_file_stat the returns the file size, times. You can then easily use
that for file size and times. Also, if you want, add an is_dir boolean
so people can write functions that walk the dir
Andreas Pflug wrote:
> Before the thread concentrates too much on a decent default value, I'm
> posting a fresh version of the patch, for some more discussion. Current
> default for pg_logfile_prefix is 'postgresql-', may the committers
> decide which name is The Perfect One.
>
> All previous s
Andreas Pflug wrote:
> Peter Eisentraut wrote:
> > Bruce Momjian wrote:
> >
> >>For logs I think pgsql_ is best because that filename is already
> >>going to be long, and I don't usually like dashes in file names.
> >>They look too much like arguments, but tarballs use them and it looks
> >>OK th
Andreas Pflug wrote:
> > I wasn't talking about what looks best, I was talking about current
> > practice for log files. From that you might be able to extrapolate
> > what other people have previously found to look best.
> >
> > In any case, we're not using DOS and 12 inch monitors any more.
Peter Eisentraut wrote:
Bruce Momjian wrote:
For logs I think pgsql_ is best because that filename is already
going to be long, and I don't usually like dashes in file names.
They look too much like arguments, but tarballs use them and it looks
OK there, I guess.
I wasn't talking about what looks
Bruce Momjian wrote:
> For logs I think pgsql_ is best because that filename is already
> going to be long, and I don't usually like dashes in file names.
> They look too much like arguments, but tarballs use them and it looks
> OK there, I guess.
I wasn't talking about what looks best, I was tal
Peter Eisentraut wrote:
> Andreas Pflug wrote:
> > Apparently it's best to invent a log_file_prefix = 'pgsql_' guc
> > variable.
>
> In any case, the prefix "postgresql-" is more in line with current
> practice.
For logs I think pgsql_ is best because that filename is already going
to be long, a
Andreas Pflug wrote:
> Apparently it's best to invent a log_file_prefix = 'pgsql_' guc
> variable.
In any case, the prefix "postgresql-" is more in line with current
practice.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
Andreas Pflug wrote:
How should the prefix be named? pgsql_ ?
Make the file names configurable.
He has code to interpret the file names as timestamps that can be
used in queries. If we allowed full user contr
Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Andreas Pflug wrote:
> > > How should the prefix be named? pgsql_ ?
> >
> > Make the file names configurable.
>
> He has code to interpret the file names as timestamps that can be
> used in queries. If we allowed full user control over the file na
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> > > Andreas Pflug wrote:
> > > > How should the prefix be named? pgsql_ ?
> > >
> > > Make the file names configurable.
> >
> > He has code to interpret the file names as timestamps that can be
> > used in queries. If we
Peter Eisentraut wrote:
> Andreas Pflug wrote:
> > How should the prefix be named? pgsql_ ?
>
> Make the file names configurable.
He has code to interpret the file names as timestamps that can be used
in queries. If we allowed full user control over the file name, he
couldn't do that.
--
Bru
Andreas Pflug wrote:
> How should the prefix be named? pgsql_ ?
Make the file names configurable.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 6: Have you searched our list archives?
ht
Andreas Pflug wrote:
> > process the timestamp field in queries. Good idea. What happens if a
> > filename matches the above pattern but isn't a valid timestamp? Does
> > the function fail?
>
> Right now, BuildTupleFromCString will fail for invalid timestamps.
>
> I'm going to change that to p
Bruce Momjian wrote:
Andreas Pflug wrote:
Very nice. You did a nice trick of reading the log filenames into a
timestamp field:
count = sscanf(de->d_name, "%04d-%02d-%02d_%02d%02d%02d_%05d.log", &yea$
You only process files that match that pattern for pg_logfiles_ls()
(perhaps this should
Andreas Pflug wrote:
> Updated patch which leaves postmaster runnable after the syslogger
> terminated due to pipe problems.
Very nice. You did a nice trick of reading the log filenames into a
timestamp field:
count = sscanf(de->d_name, "%04d-%02d-%02d_%02d%02d%02d_%05d.log", &yea$
You
Magnus Hagander wrote:
> Super-minor nitpicking from just eyeing over the patch, not actually
> checking how it works.
Reviewing the own code the most obvious things are overlooked.
>
> This patch changes the error message for pg_signal_backend() to "only
> superuser may access generic file functio
Updated patch which leaves postmaster runnable after the syslogger
terminated due to pipe problems.
Also includes an updated pg_proc.h which was totally f*cked up in my
previous posting.
Regards,
Andreas
? src/Makefile.global
? src/int2arrayveceq.diff
? src/backend/postgres
? src/backend/catalog
51 matches
Mail list logo
