pda@rsiatl.UUCP (Paul D. Anderson) (10/28/90)
I appear to misunderstand $< with a setuid program. Could someone
please help me clarify it's use?
I have a set uid program as follows:
-rwsrwsr-x 1 jgd hackers 137 Oct 28 01:42 sid
The text is as follows:
#!/usr/bin/perl -S $0 ${1+"$@"}
eval 'exec /usr/bin/perl -S $0 ${1+"$@"}'
if $0;
printf STDOUT "uid is %d going to %d \n", $<, $>;
1;
When I run the program, the output is as follows:
uid is 140 going to 140
I think that the output should read 'uid is 110 going to 140'. (jgd=140,
my uid=110.) Anyone got a clue? Since I want to validate who uses the
program, I need to be able to find out who the true invoker is.
Thanks.
-paul
--
* Paul Anderson * Crossroads Computing * (404) 565-0761 * emory!rsiatl!pda *
"SCCS: The condom of promiscuous programmers"lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (10/28/90)
In article <4520@rsiatl.UUCP> pda@rsiatl.UUCP (Paul D. Anderson) writes:
: I appear to misunderstand $< with a setuid program. Could someone
: please help me clarify it's use?
:
: I have a set uid program as follows:
:
: -rwsrwsr-x 1 jgd hackers 137 Oct 28 01:42 sid
:
: The text is as follows:
:
: #!/usr/bin/perl -S $0 ${1+"$@"}
What kind of a weird system are you on?
: eval 'exec /usr/bin/perl -S $0 ${1+"$@"}'
: if $0;
If you really need these two lines, setuid scripts shouldn't work at all.
: printf STDOUT "uid is %d going to %d \n", $<, $>;
:
: 1;
:
:
: When I run the program, the output is as follows:
:
: uid is 140 going to 140
I suspect you're running with suidperl to emulate setuid scripts, and
you don't have a seteuid() or setreuid() call, so it has to do a
setuid(), which sets both values.
: I think that the output should read 'uid is 110 going to 140'. (jgd=140,
: my uid=110.) Anyone got a clue? Since I want to validate who uses the
: program, I need to be able to find out who the true invoker is.
That'd be nice. If the problem is what I guessed, the only way around it
is to abandon suidperl and put a setuid C wrapper around it that executes
taintperl on the script. (Well, I suppose it would also be possible to
mine ps output for the uid of your parent process, but that's pretty
disgusting.)
If you didn't ask for setuid emulation when you built perl, are
you starting up a ksh that sets ruid equal to euid before going on
to exec perl?
In any event, lose the extra arguments on the #! line. Pret' near any system
that knows how to interpret #! in the kernel only allows a single argument,
and nobody of a shell persuasion is going to interpret those arguments
in a comment anyway. If you ARE on a system that knows #!, the kernel
probably only sees #!/usr/bin/perl -S, which is strange but benign.
Larrypda@rsiatl.UUCP (Paul D. Anderson) (10/29/90)
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes:
P > I appear to misunderstand $< with a setuid program. Could someone
P > please help me clarify it's use? [...]
L >What kind of a weird system are you on?
An old copy of ISC unix (Svr2) running a Korn shell from hell... :-)
L >I suspect you're running with suidperl to emulate setuid scripts, and
L >you don't have a seteuid() or setreuid() call, so it has to do a
L >setuid(), which sets both values.
I am running suidperl and the only system calls supported are setuid, setgid.
P > #!/usr/bin/perl -S $0 ${1+"$@"}
P > eval 'exec /usr/bin/perl -S $0 ${1+"$@"}'
P > if $0;
L >If you really need these lines, setuid scripts shouldn't work at all.
If I don't have those lines, exactly, this is the message
I get (sid is the program name):
Args must match #! line at sid line 1.
L >In any event, lose the extra arguments on the #! line. Pret' near any system
L >that knows how to interpret #! in the kernel only allows a single argument,
L >and nobody of a shell persuasion is going to interpret those arguments
L >in a comment anyway. If you ARE on a system that knows #!, the kernel
L >probably only sees #!/usr/bin/perl -S, which is strange but benign.
Hmmmm. Went back and validated one more time. My ksh is pretty stoopid-
I always write scripts on this machine with 'eval exec...' because the ksh
can't handle '#!'. The reason I put '#!/usr...' was because Perl was
issuing the following message:
No #! line at sid line 1.
when the set uid bit was set on the file. No setuid bit set, and the
program runs with no error messages. (I think it's perl issuing that
message ?!?)
L >If the problem is what I guessed, the only way around it
L >is to abandon suidperl and put a setuid C wrapper around it that executes
L >taintperl on the script. (Well, I suppose it would also be possible to
L >mine ps output for the uid of your parent process, but that's pretty
L >disgusting.)
That's life. I'll probably end up doing a C wrapper.
L >If you didn't ask for setuid emulation when you built perl, are
L >you starting up a ksh that sets ruid equal to euid before going on
L >to exec perl?
No, I did ask for setuid emulation and am using suidperl (indirectly, perl
is invoking suidperl on my behalf.) Should my #! line invoke suidperl
directly?
Sigh. Back to the drawing board. But, Larry, in 1 1/2 years, that's
the first time I haven't been able to use perl for what I needed. Pretty
darn good track record!
-paul
--
* Paul Anderson * Crossroads Computing * (404) 565-0761 * emory!rsiatl!pda *
"SCCS: The condom of promiscuous programmers"