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 _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
