From owner-freebsd-current Mon Nov 15 17:50:45 1999 Delivered-To: freebsd-current@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 0B57F14DF9 for ; Mon, 15 Nov 1999 17:50:40 -0800 (PST) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id RAA08909; Mon, 15 Nov 1999 17:44:12 -0800 (PST) Message-Id: <199911160144.RAA08909@implode.root.com> To: Matthew Dillon Cc: Sean Eric Fagan , current@FreeBSD.ORG Subject: Re: PATCH for testing In-reply-to: Your message of "Mon, 15 Nov 1999 14:27:10 PST." <199911152227.OAA45627@apollo.backplane.com> From: David Greenman Reply-To: dg@root.com Date: Mon, 15 Nov 1999 17:44:12 -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >:I don't think this should go in at all. >: >:It increases the size of the proc structure (thereby affecting _all_ >:processes) gratuitously. While I'm generally in favour of having the process >:arguments kept around, the "BSD way" has been to only examine them in user >:memory, despite that being unreliable and just annoying. >: >:The benefits are fairly minimal, and I don't believe justify the cost >:incurred. > > If it weren't for 'setproctitle()' I would agree with you. But since > setproctitle() exists we have a serious mess on our hands. Personally I > would prefer to see it cleaned up as follows: > > * place a copy of the initial arguments in the struct proc as well > as the uarea. > * have the sysctl that limits the buffer size within the struct proc > to something reasonable (e.g. 1K) but don't bother making 'ps' > fall back to the uarea. Allow a value of '0' indicating 'unlimited' > (i.e. really means ARGS_MAX). > * setproctitle() messes with the struct proc only > * ps, top, et all use the struct proc only > > And, also, we need to get rid of the 'e' option to ps entirely. It's a > major security hole. I agree that we need to get rid of 'e' and any other options that allow reading another process's environment. I don't agree with putting the command args in the proc struct, however, for the reason that Sean mentioned above. In my opinion, doing so majorly bloats the proc struct for no good reason and also introduces gratuitous incompatibilities for utilities that want to modify their argv[*] and expect the modifications to show up in ps(1). -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message