The C program will only return the password to registered calling programs or scripts - and checks the registered inode value to ensure it was not altered.

Uh, I did not see that. Creative, but breakable. There are editors that can edit files without altering the inode number, vi is the most common one.

For perl scripts, that does not help much, see my previous posting. You would also have to check all modules that the script may load, including the ones loaded at runtime, and the *.so for XS modules. And you would have to check that no "evil" modules are loaded. The perl debugger could be used to bypass the normal flow of operation, and of course to read the secret, so you need to check for that, too. To make things interesting, the security checks should allow updating perl modules via CPAN or distrubution packages.

/proc/$PID/comm can be modifed at runtime. I can run any program that I want and change that value so that it passes the check. And it is specific for Linux, not available elsewhere, and not on all Linux versions.

/proc/$PID/cmdline is read-only, so you could check for some tricks played on the command line. But you also have to check for several environment variables, see perlrun. You also have to check for sitecustomize.pl. And that's just perl. Other scripting languages have similar tricks.

LD_PRELOAD can do very evil stuff to any dynamically linked program, see ld.so. If I can inject a shared object that calls the secret-emitting program even before main() runs, your secret is no longer secret. So you definitively have to check the environment.

What happens for strace -o /tmp/trace /home/shared/bin/shared-program? I would expect to find the secret in /tmp/trace.

Just for fun, read suEXEC Security Model. All of these paranoid checks are there just to safely run CGIs as a different user, this program is not trying to keep anything secret.

Alexander