Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Jan 1999 09:59:05 -0500 (EST)
From:      Robert Watson <robert@cyrus.watson.org>
To:        Andrzej Bialecki <abial@nask.pl>
Cc:        Dag-Erling Smorgrav <des@flood.ping.uio.no>, hackers@FreeBSD.ORG
Subject:   Re: proposed mod to ps(1)
Message-ID:  <Pine.BSF.3.96.990111094020.11143H-100000@fledge.watson.org>
In-Reply-To: <Pine.BSF.4.02A.9901110835120.6084-100000@korin.warman.org.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 11 Jan 1999, Andrzej Bialecki wrote:

> On Sun, 10 Jan 1999, Robert Watson wrote:
> 
> > 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
> 
> while on the subject... Does any of you know how login time limits are
> enforced? I couldn't find any place where it is done, and the real-life
> evidence seems to support my view that currently they are being just
> ignored...

I don't believe they are.  As someone points out, idled is one way to
implement them.  Presumably also the time of day/etc limits would be
appropriate for implementation via a PAM authorization module to catch
people at login.  (and a bunch of the other weird stuff like advance
warning for password expiry, etc).

login classes have always seemed to me to be a kitchen sink for strange
information :-)  The implementation of various features have always
seemed a little questionable to me.  The names of the fields (having to do
with 'login') are accurate but potentially misleading for newer users of
UNIX who might not understand the distinction between being able to
'login' and being able to run a process.  There exist many ways to run a
process under UNIX without actually being logged in, and I am uncertain as
to how many of them even inflict resource limits, let alone determine if
there is some way to authorize the uid to run a process.  For example,
cron, .forward in sendmail, at (when enabled), CGI programs if web access
is not adequately disabled, etc.  An administrator should not feel
confident (currently) that if they put the user in a class with no login
capabilities and no CPU time allowed that the user will be unable to
effectively login, run processes, access files, etc.

A lot of this is presumably because of the presence of many 3rd party
applications, of course...


  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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990111094020.11143H-100000>