Without patching existing shells and avoiding process accounting on your system, your only recourse is to write yourself your own shell. The security issues involved with this make this solution impractical, so I'm afraid I have no advice for you aside from that already given. Consider that if you write your own shell, you're going to have to find some way to selectively grant access to other shells on your system, so that shell scripts can run, but interactive sessions cannot be started (thus allowing the users to execute commands via the other shell, avoiding your logging). This is non-trivial. Your best solution is to take advantage of process accounting.

Any mechanism like this is going to be inherently platform-specific. If this is a Unix system, contact your system administrator for information on configuring your system to enable process accounting, assuming it isn't already enabled. This is something that occurs at a relatively low level in Unix (but is supported essentially the same across a variety of Unix types), which is where it needs to be, since shells provide control to the system at such a high level, they can be easily tricked or circumvented, given that a lot of programs trust shells and have ways of allowing the user to drop to one.

can process accounting log via syslog? If not, this is tricky because if it is just a file on the box, it can be spoofed, right?

a

My impression is that if you want to track your users' movements, the users you generally want to track are capable of circumventing simple measures like this. Note that the shell only records what is typed into it. I can use special file-system flags to make it so that the history file can't be deleted, and can only be appended, but you're right: there's nothing to stop them from running their own shell, or writing a simple shell in Perl, completely circumventing this. The only way to "reliably" do this is to do it closer to the OS-level, which is why most Unix variants support process accounting here.

The original poster should note that what he's trying to do is hardly novel or original, and most any major company's data center will have security policies requiring such accounting, and have generally thought of ways to do it securely. I'd avoid rolling my own, as this is definitely an area that you want to build upon the work of others, as there are a million little things you have to account for or else your installation is vulnerable to being circumvented.

>>The original poster should note that what he's trying to do is hardly novel or original, and most any major company's data center will have >>security policies requiring such accounting, and have generally thought of ways to do it securely. I'd avoid rolling my own, as this is definitely >>an area that you want to build upon the work of others, as there are a million little things you have to account for or else your installation is >>vulnerable to being circumvented.

actually, I'm writing this FOR major company's data centers, precisely because no such tool exists to do this in a foolproof manner.

It may be because attempting it in userspace is just not possible...