As it turns out, there are some limitations with our custom NFS mountauthorization hack that we've discovered.First, Solaris 10 puts some security restrictions on what mountd cando; the specific bit that we ran into is it can't fork() and exec() shell scripts. Mountd can make outgoing socket connections, so we gotaround this by putting most of the complex work in an inetd-spawned'daemon'. (There is probably a way to turn this security feature off,

Let us suppose that you have a program that is setuid root but thatusually drops its setuid status and reverts to running as the user thatran it. Of course you want to do this as early as possible to reducethe potential security risks, but at the same time you might want dosome operations while still root (for reasons of either necessity orconvenience in your code structure).

Consider the following tempting sequence, presented in pseudo-code:

chdir(pw->pw_dir);
drop-

Suppose that you have a setuid program that is failing mysteriouslyand you want to see what it's doing. With normal programs you can use strace , but not even root can strace a setuid program (if you try,the program runs non-setuid).

(Yes, strace has the -u option, but it doesn't help if the setuidprogram is being run as part of a whole chain of processes in a specificenvironment and you can't just run it directly. It would be

Periodically it surprises people to learn this, but ssh is notnecessarily very fast (in the bandwidth sense). It's plenty fast fornormal interactive use, but this speed issue can matter if you aremaking large transfers with scp , rsync , or the like; depending onyour environment, ssh can go significantly slower than wire speed.

Ssh is slow because it has to encrypt and decrypt everything that goesover the wire, and this is a CPU-bound operation. How much time thistakes depends on