eboard
> "/var/run/httpd.scoreboard" (name-based shared memory failure)
>
Can you include truss/ktrace output so that actual syscall is shown?
--
Mateusz Guzik
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
following should be safe enough:
- have a dedicated RO jail
- mount to-be-updated jail under /mnt/jail or whatever
- mount sources/whatever RO under /usr/src or whatever
- run update process from inside dedicated RO jail
--
Mateusz Guzik
___
fre
you can reasonably safely assume either
solution will do the trick similarly well.
--
Mateusz Guzik
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
volved. Single-threading the process for jailing should be
fine.
Address space can be shared between multiple jails, what happens if such
a pair ends up in different jails? Preferably such a scenario would be
prohibited to avoid future accidents.
What about existing sysvshm mappings when jai
information leaks (no id list
to look at) and conflicts.
Exporting is not a problem either - a dedicated sysctl grabs JID and
dumps its ipcs. It also gets a 'recursive' flag to know whether ipcs
for its own jails should be dumped as well (if different).
--
Mateusz Guzik
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
ome other thread is forking? This may be
buggy as it is already, but that's roughly the scheme.
It looks like we have some weird miscommunication here, so let me
restate.
I do see great benefit in having jail-aware ipcs.
I do not believe the way to achieve it is to add jail-aware permission
ch
to tell
me whether given process has a shared address space. There is only a
vm_refcnt counter in vmspace which is modified on various occasions,
thus is not suitable. Adding a separate counter sucks and adding a "once
set, never cleared flag" sucks as well. Maybe there is a good method.
--
M
ot;private purposes" (i.e.
> > disregarding possible attacks with jailing processes). The real work is
> > making the whole business safe.
>
> I agree.
>
> Is there any project ongoing for this sysvipc issue?
> If any, what is needed to be done?
>
I am unaware of any work being done in the area.
I stated what needs to be done in my first e-mail.
--
Mateusz Guzik
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
l vars. Adding proper sysctls
dumping the content for given jail is trivial and so is providing
resource limits when creating a first-level jail with a separate
sysvshm. Something which cannot be as easily achieved with the patch in
question.
Possible later switch to vimage would be transparent to user
On Tue, Jun 16, 2015 at 03:45:34AM +0900, kikuc...@uranus.dti.ne.jp wrote:
> On Mon, 15 Jun 2015 12:49:16 +0200, Mateusz Guzik wrote:
> > Fundamentally the basic question is how does the implementation cope
> > with processes having sysvshm mappings obtained from 2 different jail
rk stack for their jail, they would not mind separate ipcs
either. On the other hand having separate ipcs should not require a
separate network stack. As such, does not look like this would duplicate
too much effort if VIMAGE was to become usable.
That said, this is definitely doable. I can have a
full dataset name should be exposed or not is a very different
question, does illumos do it?
Worst case it should be trivial to add a sysctl to just obfuscate the name.
--
Mateusz Guzik
___
freebsd-jail@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
e to employ epoch(9) to simplify managing of prison lifecycle
> ?
>
Some of the ref/unref cycles are probably avoidable to begin with, but
ultimately the thing to do here is to employ per-cpu reference
counting, if at all needed.
I have a wip patch to provide such a mechanism, it may or may not land
this month.
--
Mateusz Guzik
On 12/23/22, Alexander V. Chernikov wrote:
>
>
>> On 16 Dec 2022, at 16:29, Mateusz Guzik wrote:
>>
>> On 12/16/22, Zhenlei Huang wrote:
>>> Hi,
>>>
>>> While hacking `sys/kern/kern_jail.c` I got lost.
>>>
>>> There'
buggy here, from a quick read you should be able to
work around it by:
sysctl compat.linux.default_openfiles=-1
--
Mateusz Guzik
The following reply was made to PR kern/126368; it has been noted by GNATS.
From: "Mateusz Guzik" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:
Subject: Re: kern/126368: Running ktrace/kdump in jail leads to stale jails
Date: Fri, 8 Aug 2008 19:30:22 +0200
Err, I made a mistak
On Fri, Aug 08, 2008 at 06:43:38PM +, Bjoern A. Zeeb wrote:
> >The following reply was made to PR kern/126368; it has been noted by GNATS.
> >
> >From: "Mateusz Guzik" <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Cc:
> >Subject: Re: kern
On Thu, Aug 14, 2008 at 08:16:38PM -0400, alexus wrote:
> where can I get latest patch? that I can apply to 7.0-RELEASE-p3 ?
>
Sorry for very late reply, you can grab it from here:
http://student.agh.edu.pl/~frag/kern_ktrace.diff
Thanks,
--
Mateusz
scall() at Xfast_syscall+0xf7
--- syscall (507, FreeBSD ELF64, sys_jail_set), rip = 0x800ed9bdc, rsp =
0x7fffd718, rbp = 0x7f
ffd790 ---
Proposed trivial patch:
http://student.agh.edu.pl/~mjguzik/patches/jail-use-after-free.patch
--
Mateusz Guzik
___
er priorities only..
> you can always add priority from teh master (parent) environment outside.
>
Unless I seriously misunderstood something, that's the case right now.
That is, PRIV_SCHED_SETPRIORITY matters only if resulting nice parameter
would be lower.
--
Mateusz Guzik
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
gt; + tail +2 /tmp/jail.PJ5ji3QH/jail.8101
> jail: unknown parameter: ip6.addr
Try this (lightly tested):
http://people.freebsd.org/~mjg/patches/rc-jail-ip-arg.diff
Basically the idea is to pass ip4.addr and ip6.addr only when respective
addresses are specified in configuratio
The following reply was made to PR misc/174436; it has been noted by GNATS.
From: Mateusz Guzik
To: bug-follo...@freebsd.org, r...@bytecamp.net
Cc:
Subject: Re: misc/174436: [jail] Jails with numbers as names don't work
Date: Fri, 14 Dec 2012 17:01:54 +0100
Hi,
can you provide back
The following reply was made to PR kern/174436; it has been noted by GNATS.
From: Mateusz Guzik
To: Robert Schulze
Cc: bug-follo...@freebsd.org
Subject: Re: misc/174436: [jail] Jails with numbers as names don't work
Date: Mon, 17 Dec 2012 22:31:27 +0100
On Mon, Dec 17, 2012 at 02:57
The following reply was made to PR kern/174436; it has been noted by GNATS.
From: Mateusz Guzik
To: Robert Schulze
Cc: bug-follo...@freebsd.org
Subject: Re: misc/174436: [jail] Jails with numbers as names don't work
Date: Tue, 18 Dec 2012 11:18:37 +0100
On Tue, Dec 18, 2012 at 10:48
The following reply was made to PR kern/174436; it has been noted by GNATS.
From: Mateusz Guzik
To: Robert Schulze
Cc: bug-follo...@freebsd.org
Subject: Re: misc/174436: [jail] Jails with numbers as names don't work
Date: Tue, 18 Dec 2012 12:08:30 +0100
On Tue, Dec 18, 2012 at 12:01
like
> >to help finding the source, but have missed the whole new jail evolution...
> >Inside my jails, I don't have a fstab, outside I have them defined and
> >enabled with "mount" - and noticed the non-reverted umounting.
>
> I found the problem - I noticed
x27;t know, you should investigate. :) Note that the code has to
be robust in case of errors (e.g. given fs may not be unmountable
because someone from prison0 is inside).
Again, the goal is to have jails clean up automatically after anything
jailed root was permitted to do.
Thoughts?
--
Mat
erations failed, jls (or jstat) would show what resources are
remaining along with error message (say, fs could not be unmounted
because it was busy). And then the user can fix the problem and do
jail(8) -r to re-run kernel clean up or clean on his own (say, unmount
f
On Wed, Apr 24, 2013 at 07:40:21PM -0600, Jamie Gritton wrote:
> On 04/24/13 19:22, Mateusz Guzik wrote:
> >On Mon, Apr 22, 2013 at 12:29:38PM -0600, Jamie Gritton wrote:
> >>On 04/22/13 11:39, Miroslav Lachman wrote:
> >>>>This already happens when jails are cr
29 matches
Mail list logo
