Skip site navigation (1) Skip section navigation (2)

Re: SHM ids (was running pgsql 7 under Jail'ed virtual machine on FreeBSD 4.2)

From: Alex Pilosov <alex(at)pilosoft(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dave VanAuken <dave(at)hawk-systems(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: SHM ids (was running pgsql 7 under Jail'ed virtual machine on FreeBSD 4.2)
Date: 2001-01-06 01:38:30
Message-ID: Pine.BSO.4.10.10101052037320.15520-100000@spider.pilosoft.com (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-generalpgsql-hackers
What'd happen is: Operation not permitted (EPERM, -1), so its not a
problem...

-alex

On Fri, 5 Jan 2001, Tom Lane wrote:

> I said:
> > Alex Pilosov <alex(at)pilosoft(dot)com> writes:
> >> I'd suggest you do this: add a global backend_shmid_offset in ipc.c,
> >> initialized to current default, and an option to postgres to put a value
> >> there. 
> 
> > Don't waste your time.  This issue is gone in current sources.  See
> > IpcMemoryCreate and IpcSemaphoreCreate in src/backend/storage/ipc/ipc.c.
> 
> Actually, now that I think about it, you might still have a problem if
> a "jail" is what I think it is.  The current code will step past an
> existing shmem segment if it appears to be a non-Postgres memory segment
> or if it appears to belong to another running postmaster.  However, the
> test to see if the segment owner appears to be alive is
> 
>         /*
>          * If the creator PID is my own PID or does not belong to any
>          * extant process, it's safe to zap it.
>          */
>         if (hdr->creatorPID != getpid())
>         {
>             if (kill(hdr->creatorPID, 0) == 0 ||
>                 errno != ESRCH)
>             {
> 		// segment belongs to a live postmaster, so continue
> 	    }
> 	}
> 
> So the question for you is, what will happen if kill() is given a PID
> belonging to a process that's in a different "jail"?  Will it return
> some kind of permission failure, or will it claim that there is no
> such PID (ie, return ESRCH)?  If the latter, we still have a problem ...
> 
> 			regards, tom lane
> 
> 


In response to

pgsql-hackers by date

Next:From: mikeDate: 2001-01-06 02:10:31
Subject: Re: Beta2 ... ?
Previous:From: Hiroshi InoueDate: 2001-01-06 00:58:28
Subject: Re: Isn't init_irels() dangerous ?

pgsql-admin by date

Next:From: Dave VanAukenDate: 2001-01-06 02:58:33
Subject: RE: SHM ids (was running pgsql 7 under Jail'ed virtual machine on FreeBSD 4.2)
Previous:From: Alfonso PenicheDate: 2001-01-06 00:18:48
Subject: ODBC 7.x for windows

pgsql-general by date

Next:From: Tom LaneDate: 2001-01-06 01:46:24
Subject: Re: PL/pgSQL NOT NULL variables
Previous:From: gravityDate: 2001-01-06 01:15:28
Subject: Re: PHP and PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group