From owner-freebsd-threads@FreeBSD.ORG Sun Sep 18 03:10:47 2011 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38F03106564A for ; Sun, 18 Sep 2011 03:10:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id CBDF78FC08 for ; Sun, 18 Sep 2011 03:10:46 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p8I2sNNL059972 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 17 Sep 2011 19:54:25 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4E755D84.7080103@freebsd.org> Date: Sat, 17 Sep 2011 19:55:00 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 MIME-Version: 1.0 To: Gonzalo References: <201109171520.09423.tijl@coosemans.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tijl Coosemans , freebsd-threads@freebsd.org Subject: Re: thread impersonation X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 03:10:47 -0000 On 9/17/11 11:51 AM, Gonzalo wrote: > So, as a imagined, is not possible a thread impersonation on FreeBSD? > > 2011/9/17 Tijl Coosemans I'm not quite sure what you are trying to achieve, and why. each thread DOES have its own credentials but the kernel/unix spec defines them to all be the same user.. It MIGHT be possible for a thread spawned before a seteuid() to keep some of the credentials of the prior ID but I haven't looked.. Nor do I know how that would be used.. usually UID tests are made on the PROCESS credentials and not the thread credentials (which exist for other reasons). >> On Monday 12 September 2011 21:31:03 Gonzalo wrote: >>> I'm new in freeBSD and I'm looking a way to impersonate threads in >> FreeBSD. >>> In Linux I did that with setfsuid, but that only work in linux and is not >>> portable :( >> There's seteuid(2) or setuid(2) which are portable. They change the uid of >> the entire process though, not per thread. >> >>> I saw that in FreeBSD there is Jails, that could work? Is possible to >> create >>> a Jail for every new thread and "impersonate the Jail"? Maybe I'm saying >>> things without sense :( >> A jail is a form of virtualisation. It's not related to what you're trying >> to do. You can read more about jails in the handbook: >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails-intro.html >> > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > From owner-freebsd-threads@FreeBSD.ORG Mon Sep 19 11:07:16 2011 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D1451065679 for ; Mon, 19 Sep 2011 11:07:16 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 516088FC20 for ; Mon, 19 Sep 2011 11:07:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p8JB7GHk073656 for ; Mon, 19 Sep 2011 11:07:16 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p8JB7Fqh073654 for freebsd-threads@FreeBSD.org; Mon, 19 Sep 2011 11:07:15 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Sep 2011 11:07:15 GMT Message-Id: <201109191107.p8JB7Fqh073654@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 11:07:16 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/160708 threads possible security problem with RLIMIT_VMEM o threa/157040 threads [libthr] valgrind detects leaks in libthr.so.3 o threa/154893 threads pthread_sigmask don't work if mask and oldmask are pas o threa/150959 threads [libc] Stub pthread_once in libc should call _libc_onc o threa/149366 threads pthread_cleanup_pop never runs the configured routine o threa/148515 threads Memory / syslog strangeness in FreeBSD 8.x ( possible o threa/141721 threads rtprio(1): (id|rt)prio priority resets when new thread o threa/136345 threads Recursive read rwlocks in thread A cause deadlock with o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 o threa/128922 threads threads hang with xorg running o threa/127225 threads bug in lib/libthr/thread/thr_init.c o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/101323 threads [patch] fork(2) in threaded programs broken. s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/34536 threads accept() blocks other threads s threa/30464 threads [patch] pthread mutex attributes -- pshared 26 problems total. From owner-freebsd-threads@FreeBSD.ORG Mon Sep 19 11:50:06 2011 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 931F1106566B for ; Mon, 19 Sep 2011 11:50:06 +0000 (UTC) (envelope-from gonzalo.a.r@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id DD7458FC14 for ; Mon, 19 Sep 2011 11:50:05 +0000 (UTC) Received: by wwe3 with SMTP id 3so7291330wwe.31 for ; Mon, 19 Sep 2011 04:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L49b5Vr98iEWVvDbSsJ80uBkjjji2VDu2iwtHiD9aTE=; b=jIO+ZrGjbumvvjqfexc+G2XJO6irzHaZHCv8IHIYe5dbY509MWnUmNr3V0KDt2CXrU cyPLye6jwM5gUDf4U4bZ82dHCHw2qjDmBKX6hne9EqJTSNrYGlZDDlQgaCDzhO5usRck iKyDz2azvyzYfB2PFS1AkUxV+72cffcdXDDHE= MIME-Version: 1.0 Received: by 10.216.138.142 with SMTP id a14mr2635105wej.63.1316433004809; Mon, 19 Sep 2011 04:50:04 -0700 (PDT) Received: by 10.216.208.23 with HTTP; Mon, 19 Sep 2011 04:50:04 -0700 (PDT) In-Reply-To: <4E755D84.7080103@freebsd.org> References: <201109171520.09423.tijl@coosemans.org> <4E755D84.7080103@freebsd.org> Date: Mon, 19 Sep 2011 08:50:04 -0300 Message-ID: From: Gonzalo To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Tijl Coosemans , freebsd-threads@freebsd.org Subject: Re: thread impersonation X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 11:50:06 -0000 What i'm trying to achieve is a program like NFS. Users will connect to this program and navigate the virtual filesystem. Each connection is a thread, and I need to impersonate them for the user associated to each connection, if I use setuid, all thread in the process would be impersonated. In Linux I achieved that using "setfsid" but that doesn't exists here in FreeBSD Thanks Gonzalo 2011/9/17 Julian Elischer > On 9/17/11 11:51 AM, Gonzalo wrote: > >> So, as a imagined, is not possible a thread impersonation on FreeBSD? >> >> 2011/9/17 Tijl Coosemans >> > I'm not quite sure what you are trying to achieve, and why. > each thread DOES have its own credentials but the kernel/unix spec defines > them to all be the same user.. > It MIGHT be possible for a thread spawned before a seteuid() to keep some > of the credentials of the prior ID > but I haven't looked.. Nor do I know how that would be used.. usually UID > tests are made on the PROCESS > credentials and not the thread credentials (which exist for other reasons). > >> On Monday 12 September 2011 21:31:03 Gonzalo wrote: >>> >>>> I'm new in freeBSD and I'm looking a way to impersonate threads in >>>> >>> FreeBSD. >>> >>>> In Linux I did that with setfsuid, but that only work in linux and is >>>> not >>>> portable :( >>>> >>> There's seteuid(2) or setuid(2) which are portable. They change the uid >>> of >>> the entire process though, not per thread. >>> >>> I saw that in FreeBSD there is Jails, that could work? Is possible to >>>> >>> create >>> >>>> a Jail for every new thread and "impersonate the Jail"? Maybe I'm saying >>>> things without sense :( >>>> >>> A jail is a form of virtualisation. It's not related to what you're >>> trying >>> to do. You can read more about jails in the handbook: >>> http://www.freebsd.org/doc/en_**US.ISO8859-1/books/handbook/** >>> jails-intro.html >>> >>> ______________________________**_________________ >> freebsd-threads@freebsd.org mailing list >> http://lists.freebsd.org/**mailman/listinfo/freebsd-**threads >> To unsubscribe, send any mail to "freebsd-threads-unsubscribe@** >> freebsd.org " >> >> > From owner-freebsd-threads@FreeBSD.ORG Mon Sep 19 12:41:20 2011 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E00AE1065675; Mon, 19 Sep 2011 12:41:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B52358FC18; Mon, 19 Sep 2011 12:41:20 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 61E6D46B95; Mon, 19 Sep 2011 08:41:20 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E78638A03C; Mon, 19 Sep 2011 08:41:19 -0400 (EDT) From: John Baldwin To: freebsd-threads@freebsd.org Date: Mon, 19 Sep 2011 08:41:17 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E755D84.7080103@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109190841.17780.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 19 Sep 2011 08:41:20 -0400 (EDT) Cc: Robert Watson , Tijl Coosemans Subject: Re: thread impersonation X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 12:41:21 -0000 On Monday, September 19, 2011 7:50:04 am Gonzalo wrote: > What i'm trying to achieve is a program like NFS. Users will connect to this > program and navigate the virtual filesystem. Each connection is a thread, > and I need to impersonate them for the user associated to each connection, > if I use setuid, all thread in the process would be impersonated. In Linux I > achieved that using "setfsid" but that doesn't exists here in FreeBSD Yes, per-thread credentials don't exist yet. You can try asking zml@FreeBSD.org as he was planning to work on that, but I don't know if he has a patch available. rwatson@ is another good person to ask about this. -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Mon Sep 19 12:51:22 2011 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29C811065672 for ; Mon, 19 Sep 2011 12:51:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 01B198FC18 for ; Mon, 19 Sep 2011 12:51:22 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id ADBC046B46; Mon, 19 Sep 2011 08:51:21 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3A0328A02F; Mon, 19 Sep 2011 08:51:21 -0400 (EDT) From: John Baldwin To: freebsd-threads@freebsd.org, Michael Pounov Date: Mon, 19 Sep 2011 08:43:27 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <201109171150.p8HBo8lZ071542@freefall.freebsd.org> In-Reply-To: <201109171150.p8HBo8lZ071542@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201109190843.27576.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 19 Sep 2011 08:51:21 -0400 (EDT) Cc: Subject: Re: threads/160708: Bypass process stack quota :) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 12:51:22 -0000 On Saturday, September 17, 2011 7:50:08 am Michael Pounov wrote: > The following reply was made to PR threads/160708; it has been noted by GNATS. > > From: Michael Pounov > To: freebsd-gnats-submit@freebsd.org > Cc: > Subject: Re: threads/160708: Bypass process stack quota :) > Date: Sat, 17 Sep 2011 14:26:11 +0300 > > Hmm, you no so right Peter. > > Yes I can move esp pointer in any other address, but please > start program and see address of allocated memory for every thread. > All this allocations is made in upper memory called stack. > > Try same alloca() in main program thread and you see how > system terminate program if you going over stack limit. It's not very practical to apply this limit to multithreaded apps. Would you want it to be a global limit (i.e. all stacks summed together must be <= limit) or a per-thread limit (i.e. each thread's stack must be <= limit). Also, given that RLIMIT_DATA is now obsolete (since malloc() defaults to using MAP_ANON with mmap() rather than sbrk()), using RLIMIT_AS is probably the right thing if you are trying to prevent local DOS. -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Mon Sep 19 14:02:16 2011 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B30D6106566B; Mon, 19 Sep 2011 14:02:16 +0000 (UTC) (envelope-from misho@elwix.org) Received: from x0r.aitnet.org (x0r.aitnet.org [84.238.153.240]) by mx1.freebsd.org (Postfix) with ESMTP id 6DC318FC15; Mon, 19 Sep 2011 14:02:16 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by x0r.aitnet.org (Postfix) with ESMTP id 74CA53F731; Mon, 19 Sep 2011 16:43:48 +0300 (EEST) X-Virus-Scanned: amavisd-new at aitnet.org Received: from x0r.aitnet.org ([127.0.0.1]) by localhost (x0r.aitnet.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktR6gHi83ytv; Mon, 19 Sep 2011 16:43:48 +0300 (EEST) Received: from localhost (unknown [212.116.129.162]) by x0r.aitnet.org (Postfix) with ESMTPSA id 010983F72B; Mon, 19 Sep 2011 16:43:47 +0300 (EEST) Date: Mon, 19 Sep 2011 16:47:57 +0300 From: Michael Pounov To: John Baldwin Message-Id: <20110919164757.dcbae5a1.misho@elwix.org> In-Reply-To: <201109190843.27576.jhb@freebsd.org> References: <201109171150.p8HBo8lZ071542@freefall.freebsd.org> <201109190843.27576.jhb@freebsd.org> Organization: ELWIX X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-threads@freebsd.org Subject: Re: threads/160708: Bypass process stack quota :) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 14:02:16 -0000 On Mon, 19 Sep 2011 08:43:27 -0400 John Baldwin wrote: > On Saturday, September 17, 2011 7:50:08 am Michael Pounov wrote: > > The following reply was made to PR threads/160708; it has been noted by > GNATS. > > > > From: Michael Pounov > > To: freebsd-gnats-submit@freebsd.org > > Cc: > > Subject: Re: threads/160708: Bypass process stack quota :) > > Date: Sat, 17 Sep 2011 14:26:11 +0300 > > > > Hmm, you no so right Peter. > > > > Yes I can move esp pointer in any other address, but please > > start program and see address of allocated memory for every thread. > > All this allocations is made in upper memory called stack. > > > > Try same alloca() in main program thread and you see how > > system terminate program if you going over stack limit. > > It's not very practical to apply this limit to multithreaded apps. Would you > want it to be a global limit (i.e. all stacks summed together must be <= > limit) or a per-thread limit (i.e. each thread's stack must be <= limit). > Also, given that RLIMIT_DATA is now obsolete (since malloc() defaults to using > MAP_ANON with mmap() rather than sbrk()), using RLIMIT_AS is probably the > right thing if you are trying to prevent local DOS. > > -- > John Baldwin My opinion from security viewpoint is all stacks summed together must be <= limit. Also reasonable solution is each thread's stack must be <= limit. Problem is not from own software, problem appears from buggy software of customer installed on server. I am not happy with that, when customer able get all resources with user account. This should be avoided when posible. -- Michael Pounov From owner-freebsd-threads@FreeBSD.ORG Mon Sep 19 14:42:50 2011 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3E0C106566B for ; Mon, 19 Sep 2011 14:42:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8B2278FC18 for ; Mon, 19 Sep 2011 14:42:50 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4217A46B45; Mon, 19 Sep 2011 10:42:50 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D00B98A02E; Mon, 19 Sep 2011 10:42:49 -0400 (EDT) From: John Baldwin To: Michael Pounov Date: Mon, 19 Sep 2011 10:42:49 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <201109171150.p8HBo8lZ071542@freefall.freebsd.org> <201109190843.27576.jhb@freebsd.org> <20110919164757.dcbae5a1.misho@elwix.org> In-Reply-To: <20110919164757.dcbae5a1.misho@elwix.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109191042.49287.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 19 Sep 2011 10:42:49 -0400 (EDT) Cc: freebsd-threads@freebsd.org Subject: Re: threads/160708: Bypass process stack quota :) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 14:42:50 -0000 On Monday, September 19, 2011 9:47:57 am Michael Pounov wrote: > On Mon, 19 Sep 2011 08:43:27 -0400 > John Baldwin wrote: > > > On Saturday, September 17, 2011 7:50:08 am Michael Pounov wrote: > > > The following reply was made to PR threads/160708; it has been noted by > > GNATS. > > > > > > From: Michael Pounov > > > To: freebsd-gnats-submit@freebsd.org > > > Cc: > > > Subject: Re: threads/160708: Bypass process stack quota :) > > > Date: Sat, 17 Sep 2011 14:26:11 +0300 > > > > > > Hmm, you no so right Peter. > > > > > > Yes I can move esp pointer in any other address, but please > > > start program and see address of allocated memory for every thread. > > > All this allocations is made in upper memory called stack. > > > > > > Try same alloca() in main program thread and you see how > > > system terminate program if you going over stack limit. > > > > It's not very practical to apply this limit to multithreaded apps. Would you > > want it to be a global limit (i.e. all stacks summed together must be <= > > limit) or a per-thread limit (i.e. each thread's stack must be <= limit). > > Also, given that RLIMIT_DATA is now obsolete (since malloc() defaults to using > > MAP_ANON with mmap() rather than sbrk()), using RLIMIT_AS is probably the > > right thing if you are trying to prevent local DOS. > > > > -- > > John Baldwin > > My opinion from security viewpoint is all stacks summed together must be <= limit. > Also reasonable solution is each thread's stack must be <= limit. Yes, both are reasonable, which is part of why it is hard to apply the limit in a generic sense. Someone will get bitten by assuming it works one way when it actually works another. > Problem is not from own software, problem appears from buggy software of customer installed on server. I am not happy with that, when customer able get all resources with user account. > This should be avoided when posible. And RLIMIT_STACK is not a good tool for this. RLIMIT_AS is a much better tool this limits the total virtual memory usage including stack, text, data, and the heap while allowing individual programs more freedom with what mix they use. That is, if you just want to limit processes to 8GB of memory, do you really care if it uses 4GB of stack and 2GB of heap vs 512MB of stack and 5.5GB of heap? I don't think an admin should care about that, what they really want to limit is the amount of memory used so they can avoid swapping, etc. -- John Baldwin