From owner-freebsd-hackers Thu Aug 7 23:07:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA25415 for hackers-outgoing; Thu, 7 Aug 1997 23:07:03 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id XAA25409 for ; Thu, 7 Aug 1997 23:06:59 -0700 (PDT) Received: from tom by misery.sdf.com with smtp (Exim 1.62 #1) id 0wwiB2-000076-00; Thu, 7 Aug 1997 23:05:32 -0700 Date: Thu, 7 Aug 1997 23:05:31 -0700 (PDT) From: Tom Samplonius To: David Nugent cc: Alan Batie , hackers@freebsd.org Subject: Re: login classes In-Reply-To: <199708080421.OAA00454@labs.usn.blaze.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 8 Aug 1997, David Nugent wrote: > > Since daemon hasn't logged in, or been > > executed by something that can set the resource limits? > > You're confusing logins with login classes, I think. :-) I'm assuming that the login process was the only thing that set the resource limits from that users login class. I had no idea that init set these as well. I was also surprised about cron, so I'll have to upgrade some boxes. Do you have a comprehensive list of things that are setting the login class? > > Also, the issue here is that Alan probably wants smsh NOT to have the > > limits of daemon, but of that user. Lot of users screw up, and put junk > > in their .forward file, and when they get mail they end of chewing up CPU, > > and/or RAM. > > Hmm. Then there's the other tack that mail delivery will unnecessarily > fail because user resources are generally lower than the daemon class. Hmm, does mail delivery really require a lot of resources? ... > There are arguments both ways. Personally I rely on the current behaviour, > as procmail in particular tends to consume a lot of memory with large > messages; more memory than I allow for shell users. I don't like procmail, I wish there was a simple filter that just looked a headers, rather than scanning the entire message. It also doesn't support more "modern" mailbox types. > The only other area I am aware of where there is a 'hole' is at(1), > which is on the todo list. Other things keep cropping up and get > higher on the list. :) Hmmm, doesn't wu-ftpd allow users to exec via "SITE EXEC"? wu-ftpd isn't installed by default, but you have to vigilant. I guess this is kinda of ports issue... > Regards, > David Tom