Date: Mon, 16 Feb 2004 16:53:15 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Maxim Konovalov <maxim@macomnet.ru> Cc: current@FreeBSD.org Subject: Re: Jails that keep hanging around Message-ID: <20040216155315.GG14639@garage.freebsd.pl> In-Reply-To: <20040216175831.G39007@news1.macomnet.ru> References: <200402151714.26631.freebsd-current@webteckies.org> <20040215191756.P49729@news1.macomnet.ru> <20040216133617.GD14639@garage.freebsd.pl> <20040216164605.S19111@news1.macomnet.ru> <20040216140720.GE14639@garage.freebsd.pl> <20040216175831.G39007@news1.macomnet.ru>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Mon, Feb 16, 2004 at 06:12:18PM +0300, Maxim Konovalov wrote: +> > +> What I really do not understand why we do not leak in non-jail +> > +> environment? +> > +> > I'm sure we are, this is just hard to check, because we don't have +> > list with allocated 'cred' structures. +> > +> > But try to do your test without a jail and track 2nd column in: +> > +> > # sysctl kern.malloc | grep cred +> > +> > Number of objects grows when I'm killing daemon while connection +> > exists. I'm wondering if this cannot be used to some DoS attack. +> +> Can't reproduce: +> +> $ vmstat -m | grep cred +> cred 38 5K 5K 22714 128 +> +> [ serveral nc & telnet tests I port early in non-jail environment ] +> +> $ vmstat -m | grep cred +> cred 38 5K 5K 22833 128 Probably, because no new cred structure is allocated when you run 'nc' without a jail (only this one used by your shell is referenced again). Try to do: # su - <some_user> -c "/usr/local/bin/nc -p 1234 -l 127.0.0.1" -- Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQFAMOdrForvXbEpPzQRAmlhAKDQQDB4WnhkRDXx6+Yairew4YrstwCg73xH Ts7G7aY70BFvgPknoYH0BB4= =cU3h -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040216155315.GG14639>