Detect name and path of calling script

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Hi
I'm fairly new to Perl and have a problem I can't find an answer for yet
I have a perl script which is called from a ksh script. I wish to make sure that the perl script is only being called from this parent ksh script whose location and name I know.
I don't want the perl script to be called directly
e.g.

/path/I/know/MAINSCRIPT.KSH calls PERLSCRIPT

PERLSCRIPT.pl
-------------
check I'm being called by /path/I/know/MAINSCRIPT.KSH
if no exit
else continue
[download]

The perlscript is made into an executable via perlcc and given setuid

How do I do this in perl ?

Comment on Detect name and path of calling script Download Code

Replies are listed 'Best First'.
Re: Detect name and path of calling script by derby (Abbot) on Apr 08, 2008 at 13:11 UTC
Well ... on *nix systems, you cannot reliably do this. Sure, you can get the current process pid, look up the parent pid in the process table and then check the name of the parent process ... but you see, the name of a process is easily spoofed. What exactly are you trying to accomplish? There may be better ways (sudo) to accomplish what you really need. -derby	[reply]
Re^2: Detect name and path of calling script by Anonymous Monk on Apr 08, 2008 at 13:45 UTC
This is a *nix system. Unfortunately sudo is not installed on the system (and is not likely to be) or yes I would have used it So in a nutshell I'm trying to achieve what sudo would have given me but without the ability to use sudo.	[reply]
Re: Detect name and path of calling script by oko1 (Deacon) on Apr 08, 2008 at 15:08 UTC
I suggest you rethink the whole idea from scratch. The solution to your problem has no relation to Perl - or, for that matter, any programming language. You're giving SUID to an executable via a non-secure process - this is an invitation to anyone on the system to grab UID0 (root) at will. The correct solution requires securing the chain of trust that leads to the creation and execution of your SUID program; this means using 'su', 'sudo', 'super', or some other mechanism which will securely authenticate the valid user (rather than a program.) If you don't have such a mechanism, you can't do it securely (caveat: all rules are suspended for super-geniuses.) If you try, you're betting your knowledge and understanding against the many years of refinement produced by the constant attack/counterattack scenario that has resulted in the creation of the programs I've mentioned. That's a very, very poor bet. -- Human history becomes more and more a race between education and catastrophe. -- HG Wells	[reply]