Обсуждение: buffer overflow
I am consistently getting these NOTICEs as I work with postgresql 7.1.2 and 7.1.3. NOTICE: RegisterSharedInvalid: SI buffer overflow NOTICE: RegisterSharedInvalid: SI buffer overflow NOTICE: InvalidateSharedInvalid: cache state reset NOTICE: RegisterSharedInvalid: SI buffer overflow NOTICE: InvalidateSharedInvalid: cache state reset ... psql:/tmp/laurette23849/jobseq.sql:23228: NOTICE: InvalidateSharedInvalid: cache state reset psql:/tmp/laurette23849/jobseq.sql:23228: NOTICE: InvalidateSharedInvalid: cache state reset What can be done to "fix" them? Thanks, -- Laurette Cisneros (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com Passenger Information Everywhere
I have no answer to this, but I'll add my experience to the question. I'm getting the same message, but in my case it is not consistent. It is always during a cron job that does a vacuum analyze in the middle of the night, but not every time the job runs. If I do the same thing interactively (the vacuum/analyze), I don't get the message, so I only see the messages about once a week & can't reproduce the problem reliably. It doesn't appear that anything is "broken" when we get this message- everything keeps running well. Any thoughts? Thanks -Nick > -----Original Message----- > From: pgsql-admin-owner@postgresql.org > [mailto:pgsql-admin-owner@postgresql.org]On Behalf Of Laurette Cisneros > Sent: Wednesday, October 03, 2001 12:33 PM > To: pgsql-admin@postgresql.org > Subject: [ADMIN] buffer overflow > > > > I am consistently getting these NOTICEs as I work with postgresql > 7.1.2 and 7.1.3. > > NOTICE: RegisterSharedInvalid: SI buffer overflow > NOTICE: RegisterSharedInvalid: SI buffer overflow > NOTICE: InvalidateSharedInvalid: cache state reset > NOTICE: RegisterSharedInvalid: SI buffer overflow > NOTICE: InvalidateSharedInvalid: cache state reset > ... > psql:/tmp/laurette23849/jobseq.sql:23228: NOTICE: > InvalidateSharedInvalid: cache state reset > psql:/tmp/laurette23849/jobseq.sql:23228: NOTICE: > InvalidateSharedInvalid: cache state reset > > What can be done to "fix" them? > > Thanks, > > -- > Laurette Cisneros > (510) 420-3137 > NextBus Information Systems, Inc. > www.nextbus.com > Passenger Information Everywhere > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
On Mon, 8 Oct 2001, Nick Fankhauser wrote: > I have no answer to this, but I'll add my experience to the question. > > I'm getting the same message, but in my case it is not consistent. It is > always during a cron job that does a vacuum analyze in the middle of the > night, but not every time the job runs. If I do the same thing interactively > (the vacuum/analyze), I don't get the message, so I only see the messages > about once a week & can't reproduce the problem reliably. > > It doesn't appear that anything is "broken" when we get this message- > everything keeps running well. They should be safe (mostly a debugging message). IIRC, there were known bugs in earlier versions that happened on the reset, but that these were fixed and noone has found any since but the messages were still there. They're getting downgraded from NOTICE to DEBUG in 7.2 I think.
Hi Gurus,
Greetings. I am using Postgresql in Red hat linux 71. When i was trying
to take the backup it is giving the error "Permission Denied"
Did any one faced the Same problem.
I will tell u what are the things which i did
1. Login as root
2. su -l postgres
3. pg_dump databasename >filename
Where other things are working fine. Only when i was trying to take the
backup i am getting the problem. Please let me know some guidence
Thanks
Mudhalvan M.M
you should make sure, that you have 'rwx' access to the directory you're
trying to send the output to. Make sure, all your postgres files under the
postgres home (~postgres) as well as all directories are actually owned by
postgres. If they are not, this small script can change that:
cd ~postgres
find . -depth -exec chown postgres:postgres {} ";"
Best regards,
Chris
----- Original Message -----
From: "Moovarkku Mudhalvan" <mudhalvan@vasunas.com>
To: "Stephan Szabo" <sszabo@megazone23.bigpanda.com>; "Nick Fankhauser"
<nickf@ontko.com>
Cc: "Laurette Cisneros" <laurette@nextbus.com>; <pgsql-admin@postgresql.org>
Sent: Wednesday, October 10, 2001 7:00 AM
Subject: [ADMIN] Permission Denied When i am Trying to take Backup
> Hi Gurus,
>
> Greetings. I am using Postgresql in Red hat linux 71. When i was
trying
> to take the backup it is giving the error "Permission Denied"
> Did any one faced the Same problem.
> I will tell u what are the things which i did
>
> 1. Login as root
> 2. su -l postgres
> 3. pg_dump databasename >filename
>
> Where other things are working fine. Only when i was trying to take the
> backup i am getting the problem. Please let me know some guidence
>
> Thanks
> Mudhalvan M.M
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Hi! > Greetings. I am using Postgresql in Red hat linux 71. When i was trying >to take the backup it is giving the error "Permission Denied" > 1. Login as root > 2. su -l postgres > 3. pg_dump databasename >filename Who gives you the "Permission denied"? The shell? The postmaster? What is the exact error message? I guess, you dno't have permission to create a file as user postgres in the directory you are working in. If you followed the installatino guide step by step, the postgres files/directories are owned by root, not by postgres. I always do a chown -R postgres:daemon /usr/local/pgsql (or postgres:postgres) after installation. Stefan -- Cameron's Law: An honest politician is one who, when he is bought, will stay bought.
Perhaps postgres doesn't have rights to create <filename> in the current directory? To test this, try to use the same procedure & at step 3, do: touch <filename> instead of starting dump. If it fails, you have the answer. What does the "-l" option on su do? (I'm unfamiliar with it & apparently don't have such an option on the version I'm running.) > -----Original Message----- > From: Moovarkku Mudhalvan [mailto:mudhalvan@vasunas.com] > Sent: Wednesday, October 10, 2001 7:01 AM > To: Stephan Szabo; Nick Fankhauser > Cc: Laurette Cisneros; pgsql-admin@postgresql.org > Subject: Permission Denied When i am Trying to take Backup > > > Hi Gurus, > > Greetings. I am using Postgresql in Red hat linux 71. When i > was trying > to take the backup it is giving the error "Permission Denied" > Did any one faced the Same problem. > I will tell u what are the things which i did > > 1. Login as root > 2. su -l postgres > 3. pg_dump databasename >filename > > Where other things are working fine. Only when i was trying to take the > backup i am getting the problem. Please let me know some guidence > > Thanks > Mudhalvan M.M >
Stefan Huber writes: > If you followed the installatino guide step by step, the postgres > files/directories are owned by root, not by postgres. Which is a good idea. > I always do a chown -R postgres:daemon /usr/local/pgsql (or > postgres:postgres) after installation. Which is a bad idea. The installation instructions were developed with some thought behind them. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Could someone create a post that shows who(user) should own what. I have always let postgres own the pgsql directory and I see that it is recomended that root own it. Thanks, Ted -----Original Message----- From: Peter Eisentraut <peter_e@gmx.net> To: Stefan Huber <looseleaf@gmx.net> Date: Thu, 11 Oct 2001 22:03:28 +0200 (CEST) Subject: Re: [ADMIN] Permission Denied When i am Trying to take Backup > Stefan Huber writes: > > > If you followed the installatino guide step by step, the postgres > > files/directories are owned by root, not by postgres. > > Which is a good idea. > > > I always do a chown -R postgres:daemon /usr/local/pgsql (or > > postgres:postgres) after installation. > > Which is a bad idea. > > The installation instructions were developed with some thought behind > them. > > -- > Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter > > > ---------------------------(end of > broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly
Hi! > > I always do a chown -R postgres:daemon /usr/local/pgsql (or > > postgres:postgres) after installation. > >Which is a bad idea. > >The installation instructions were developed with some thought behind >them. Well, this might be true, if you are on a system, where more than one humans are operating. Or are there some other reasons behind this philosophy? I mean, a buffer overflow (I don't claim to know of any in Postgres) can cause more problems when running as root than as user. Can anyone explain these thoughts behind the instructions? Or pinpoint me to the explanations in the docs. Stefan -- Murphy's Airport Axiom: Your flight never leaves from gate #1.
On Fri, 12 Oct 2001, postgresql wrote:
> Could someone create a post that shows who(user) should own
> what. I have always let postgres own the pgsql directory and I see
> that it is recomended that root own it.
Whenver I have installed postgres (as the postgres user), it has always
installed everything owned by postgres:postgres. I've never installed
postgres as root, except for the Perl interfaces (which must be installed
by root). This was the recommended procedure in earlier version of
PostgreSQL, but it seems in the newer documentation, it recommends
*against* installing as the postgres super-user.
-- Brett
http://www.chapelperilous.net/
------------------------------------------------------------------------
Toddlers are the stormtroopers of the Lord of Entropy.
On Fri, 12 Oct 2001, Stefan Huber wrote:
> Well, this might be true, if you are on a system, where more than one
> humans are operating. Or are there some other reasons behind this philosophy?
> I mean, a buffer overflow (I don't claim to know of any in Postgres) can
> cause more problems when running as root than as user.
You should never run Postgres as root, regardless of whether or not root
owns the executables. The server should still always be run as a
non-priveleged user.
-- Brett
http://www.chapelperilous.net/
------------------------------------------------------------------------
La-dee-dee, la-dee-dah.
On Friday, October 12, 2001, at 10:33 PM, postgresql wrote: > > Could someone create a post that shows who(user) should own > what. I have always let postgres own the pgsql directory and I see > that it is recomended that root own it. > The PostgreSQL processes should be run as an unprivilidged user (generally a user called 'postgres'). This user should have the minimal rights to function, which in this case is write access to the data directory. This is why the rest of PostgreSQL should be installed owned by another user (generally root). This ensures that if the postgres user account is compromised, the rights it gains an attacker are minimal. All it can do is trash your database. If the PostgreSQL executables were writable by the postgres user, an attacker could install a trojan (eg. a simple wrapper around pgsql) and compromise further accounts on the system, eventually getting to root. The truely paranoid mount whatever they can from a read-only file system (eg. CDROM or a network file system). The same methodology should apply to all background services that do not require being run as root. Even software which does require root privs generally drop their privs as soon as possible (eg. Apache). -- Stuart Bishop <zen@shangri-la.dropbear.id.au>
Stefan Huber <looseleaf@gmx.net> writes:
> Well, this might be true, if you are on a system, where more than one
> humans are operating. Or are there some other reasons behind this philosophy?
The idea is that the executables shouldn't be writable by the postgres
user. That way, even if some db user manages to break into your
database superuser account, the amount of damage he can do is limited.
This has got nothing to do with whether your server system has other
people on it: as long as someone can connect as superuser, they can
cause the backend to scribble on any file that's writable by postgres.
$PGDATA and the files and directories under it need to be owned/writable
by the postgres user, but there's no reason for the rest of the
installation (bin, lib, share, etc) to be writable by the postgres user.
So doing "make install" as root and "initdb" as postgres sets you up
more securely than doing the install as postgres.
regards, tom lane