From owner-freebsd-hackers Sun Jan 10 20:24:33 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA29079 for freebsd-hackers-outgoing; Sun, 10 Jan 1999 20:24:33 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA29074 for ; Sun, 10 Jan 1999 20:24:31 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id XAA12630; Sun, 10 Jan 1999 23:23:36 -0500 (EST) Date: Sun, 10 Jan 1999 23:23:36 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Dag-Erling Smorgrav cc: hackers@FreeBSD.ORG Subject: Re: proposed mod to ps(1) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 7 Jan 1999, Dag-Erling Smorgrav wrote: > Wouldn't it make sense to add an option to ps(1) to display the login > class of each process? I was under the impression that 'login class' was really a property of the class database in userland, and that the kernel didn't know what class you were in, just the current process properties (resource limits, etc). Programs such as 'login' set their resource limitations based on these class entries. As such, ps would not know the 'class' on a per-process basis. On the other hand, modifying ps to display current resource limits (possibly with authorization checking?) would be *extremely* useful for debugging problems on large server machines :). Instead of having processes fail to start because for some reason or another they end up with the wrong resource limits (such as sshd not correctly setting the class) I could ps and see which processes end up with which properties. It might be something to add to procfs as a 'limits' entry containing formatted limit data that could be interpretted as appropriate. It's not clear whether the ability to modify limits for other processes is desirable, and if so, whether procfs is an appropriate venue for this behavior (it certainly would be cool :). If it were, the permissions on the file could be used to restrict who could do it in a general way--presumably existing restrictions on soft/hard limits, etc, would be observed (normal uid's could lower hard, and bump soft up to hard or not; root could modify hard and soft limits). This might be beyond the scope of procfs, or just plain undesirable. Either way, having the data readable there with appropriate permissions would be useful for debugging a variety of resource-related problems, and probably clarify the behavior of resource limits for a lot of people. Also, it would make it far easier to track down setuid programs that do not correctly impose limits when switching to a uid for a login-style session. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message