Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 6 Feb 2005 00:00:07 +0100
From:      Anthony Atkielski <atkielski.anthony@wanadoo.fr>
To:        freebsd-questions@freebsd.org
Subject:   Re: Running top without a shell -- more questions
Message-ID:  <971531375.20050206000007@wanadoo.fr>
In-Reply-To: <20050205100125.C47038@starfire.mn.org>
References:  <51563600.20050205125343@wanadoo.fr> <20050205100125.C47038@starfire.mn.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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?

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?

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.

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.

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

-- 
Anthony




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?971531375.20050206000007>