discussions
of workarounds, I'm wondering whether our shared memory code might have
similar risks. Does FBSD 6 also lie about the existence of other-jail
processes connected to a shared memory segment --- ie, in
shmctl(IPC_STAT)'s result, does shm_nattch count only proce
ompromise would be to have the
SysV-IPC-allowed-in-jails switch also restore the normal return value
of kill(). This seems sensible to me because the GETPID feature makes
PIDs be part of the API that is exposed across jails.
regards, tom lane
System
> V IPC across jails (as opposed to in a single jail) unsupported, since it's
> not consistent with the security model.
That'd be fine with me --- the problem here is that we've got unwanted
communication across jails. If, say, the
That
behavior is inconsistent: if process A can affect the state of a sema
set that process B can see, it's surely unreasonable to pretend that A
doesn't exist.
regards, tom lane
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Kris Kennaway <[EMAIL PROTECTED]> writes:
> On Sun, Apr 02, 2006 at 11:17:49PM -0400, Tom Lane wrote:
>> I have no objection to doing that, so long as you are actually doing it
>> correctly. This example shows that each jail must have its own SysV
>> semaphore key sp
Kris Kennaway <[EMAIL PROTECTED]> writes:
> On Sun, Apr 02, 2006 at 11:08:11PM -0400, Tom Lane wrote:
>> If this is the story, then FBSD have broken their system and must revert
>> their change. They do not have kernel behavior that totally hides the
>> existenc
broken their system and must revert
their change. They do not have kernel behavior that totally hides the
existence of the other process, and therefore having some calls that
pretend it's not there is simply inconsistent.
regards, tom lane
_
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Sun, 2 Apr 2006, Tom Lane wrote:
>> OK, could we see strace (or whatever BSD calls it) output for the second
>> postmaster? I'd like to see exactly what results it's getting for the
>> kernel calls
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Sun, 2 Apr 2006, Tom Lane wrote:
>> BTW, even before doing that, you should look at "ipcs -s" output to try
>> to get a clue what's going on. The EINVAL failures may be because the
>> secon
ance work mem that high for VACUUM? A quick and dirty solution
would be to bound the dead-tuples array size at something more sane...
regards, tom lane
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
servers...)
The ulimit the backend is running under couldn't change depending on
where the client is su'd to.
Is it possible that you've got per-user configuration settings that
affect this, like a different maintenance_mem value for the root
11 matches
Mail list logo
