Running top without a shell -- more questions

John john at
Sat Feb 5 15:24:53 PST 2005

On Sun, Feb 06, 2005 at 12:00:07AM +0100, Anthony Atkielski wrote:
> John writes:
> J> I am not seeing what you are seeing.  I see a login process hanging
> J> around with the regular shells, just like you are describing for top.
> It has occurred to me that all my other logins are ssh, so maybe that's
> the difference.  I don't have telnetd running at all.

I logged in directly to a vtty.  No telnet, sshd, just me and the

> J> There's no magic about being a shell.  You could write your own.
> J> Login isn't treating top any differently than a conventional shell
> J> in my system.
> OK.  Which by extension means that there aren't any big security
> concerns in writing a special-purpose program that replaces the shell
> for a specific user, right?  For example, if one user is allowed to
> execute only a single interactive program and nothing else, I could just
> run that program as his shell and not allow him to run a conventional
> shell at all, right?  If so, it seems like that would be a lot more
> secure, provided that the replacement program doesn't have any
> shell-like functions (such as user-initiated calls to other programs)
> that could be exploited to breach security.  Heck, that would mean that
> I could even set up a special user that does nothing but allow someone
> to play "adventure," no?

No, there are HUGE security concerns.  The big problem is that
many things have shell escapes.  Top, as far as I know, does not.

> 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.

> 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

More information about the freebsd-questions mailing list