Running top without a shell -- more questions

[Loren M. Lang]

On Sat, Feb 05, 2005 at 05:24:51PM -0600, John wrote:
> On Sun, Feb 06, 2005 at 12:00:07AM +0100, Anthony Atkielski wrote:
> > John writes:
> > 
<snip>
> 
> > J> Once upon a time, like version 7 Unix, login would simply make an
> > J> exec-family call to replace itself with the desired "shell" after
> > J> doing all the setup, ID's changes, and so forth, and that would
> > J> cause init to spawn a new getty when the wait for that pid returned.
> > J> It was simple, and it was elegant, it reclaimed the resources used
> > J> by login (this was in the days of 64k data space + 64k program code
> > J> space, period), but there was no reliable way to collect logout
> > J> information, so that hasn't been true in a long, long time.
> > 
> > Someone gains the terminal back after logout (init?); wouldn't that
> > program be able to handle logout accounting?
> 
> init never knew who was logged in.  Getty gets the user's name,
> login gets the password - but that information never goes back
> to init.

init doesn't need to know who was logged, just what tty it's on.  The
accounting information that programs like who use to show who's logged
it the wtmp and/or utmp files which are updated by init, getty, login,
X, ssh, etc.  init first forks off a new process which becomes getty.
getty will then exec login which then execs the user shell.  The user's
shell is still the child process of init and when it exits, init gets a
signal and then updates wtmp/utmp saying the user's no longer logged in.

Now on more recent unices, login has a tendency to fork a new process
for the shell and stay around, but it's not to update wtmp/utmp, init
will do that.  When I looked through the linux source code of login a
while back, it had an ifdef which added in code for dealing which the
pam authentication.  If pam was disabled, login would behave like
traditional unices and just exec the shell, but with pam it would make a
call to the pam session modules that a user is logging on and stick
around to tell the pam session module that the user has logged out.
This is needed since init knows nothing of pam and has no need to.  An
example pam session module would be one that updates the permissions on
the dsp device files so that whoever logged into the console would have
permission to use the sound card, and reset the permissions to root when
the user logs out.  Now if that same user logged remotely with ssh
instead, they won't be granted use of the sound card so they can't do
something like listen on the mic to spy on who ever is logged into the
console instead.  The regular accounting going on though is still
maintained by init and login which login first starts, not by pam.

> 
> > J> What you could do is actually not run login, either.  You could
> > J> modify /etc/ttys to call your own little buffer program.   You
> > J> do NOT want to change /etc/ttys to run top directly, because it
> > J> would be running as root, and top has a built in k (kill) command,
> > J> so you would not want to have that!
> > 
> > I prefer to avoid changing any of the standard software; updates become
> > a nightmare when you have custom mods out there.
> 
> No, no!  I am not suggesting changing the standard software!  I'm
> not saying to change getty or login, just the usual configuration
> file that controls where the system runs gettys (or xdm, or what
> have you).  This is no more changing "standard software" than
> making entries in rc.conf.
> 
> > I've modified login programs on other systems (not UNIX systems), and
> > they are maintenance and security nightmares, although you can do all
> > sorts of cool stuff.
> 
> I'm not suggesting you do so.
> 
> > Thanks for the other suggestions, though.  I'll look them up if I ever
> > wish to again tread the dangerous path of site modifications to standard
> > software (right now, I just don't have the time to open that can of
> > worms, alas!).
> 
> I'm not suggesting you modify any standard software.  I'm not suggestion
> you run a custom getty for all your logins.  I'm just saying that
> rather than running ANY login softwater at all - just use init
> to run top instead!
> 
> Look - if this makes you more comfortable - just turn off logins
> ENTIRELY on one ttyv.  Then use the program I wrote to just run
> top on the ttyv on which logins are no-longer allowed.  You could
> start it with cron or /etc/rc.d something instead of /etc/ttys.
> It doesn't matter how it gets started - the point is, NO LOGIN AT
> ALL is allowed on that terminal - how is that a security risk?
> 
> You don't have to log in as top or root or anything - no logins -
> top just runs as the user YOU specify....
> -- 
> 
> John Lind
> john at starfire.MN.ORG
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"

-- 
I sense much NT in you.
NT leads to Bluescreen.
Bluescreen leads to downtime.
Downtime leads to suffering.
NT is the path to the darkside.
Powerful Unix is.

Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc
Fingerprint: B3B9 D669 69C9 09EC 1BCD  835A FAF3 7A46 E4A3 280C