Date: Fri, 08 Aug 1997 14:21:27 +1000 From: David Nugent <davidn@labs.usn.blaze.net.au> To: Tom Samplonius <tom@sdf.com> Cc: Alan Batie <batie@aahz.jf.intel.com>, hackers@FreeBSD.ORG Subject: Re: login classes Message-ID: <199708080421.OAA00454@labs.usn.blaze.net.au> In-Reply-To: Your message of "Thu, 07 Aug 1997 18:55:59 MST." <Pine.BSF.3.95q.970807185140.24596A-100000@misery.sdf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I don't see why this is necessary. Increase resources in your *daemon* > > class since that's what applies here. The user's resources aren't > > involved except when it comes to counting resource use for that user. > > Will this actually work? Yes. Daemon is the default class used by init. Unless specifically modified, anything started by init (which is almost everything) inherits resources of the daemon class since that's how /etc/rc and friends are started. > 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. :-) > 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. I may have to revisit this one, I think. Technically this makes .forward a "security hole" which a user could exploit to gain more resources, but with smrsh in particular, the administrator already has some fairly direct control on what can and cannot be run from .forward files, so this "flaw" is a noop. But it isn't like the administrator doesn't already have some control, since there's the daemon class fallback, or sendmail could be started using limits(1) to set more appropriate limits for mail delivery (globally). Perhaps /etc/rc.conf should be modified to contain a $sendmail_command variable as well, which would better facilitate this (and alternative mailer daemons as well). 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. 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. :) Regards, David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708080421.OAA00454>