RE: Problem with system()
RE: Problem with system()
- Subject: RE: Problem with system()
- From: Norm Green <email@hidden>
- Date: Fri, 6 Jul 2007 15:26:05 -0700
Title: RE: Problem with system()
Thanks for all the suggestions, I really appreciate it.
Using /bin/date instead of date yields the same error.
Running :
rc = system("/bin/date");
(with no file redirect) succeeds and gives rc == 0.
/bin/sh looks as I'd expect it to (not a sym link)
email@hidden:132 % ls -l /bin/sh
-r-xr-xr-x 1 root wheel 1068844 Dec 18 2006 /bin/sh*
email@hidden:133 %
And I'm using the default shell (no special builds or other nonsense):
email@hidden:135 % /bin/sh --version
GNU bash, version 2.05b.0(1)-release (powerpc-apple-darwin8.0)
Copyright (C) 2002 Free Software Foundation, Inc.
email@hidden:136 %
And I'm not running as root (I know that's a big no-no)
email@hidden:133 % whoami
normg
email@hidden:134 %
And I don't have a .profile or .bashrc to mess things up.
Norm
-----Original Message-----
From: Terry Lambert [mailto:email@hidden]
Sent: Friday, July 06, 2007 1:38 PM
To: chas williams - CONTRACTOR
Cc: Norm Green; email@hidden
Subject: Re: Problem with system()
On Jul 6, 2007, at 12:08 PM, chas williams - CONTRACTOR wrote:
> In message <email@hidden
> >,Nor
> m Green writes:
>> int rc = system("date >/usr/tmp/tmp.kPCvVa");
>>
>> If fails with rc == 256 and errno == 0 and prints this to stderr:
>>
>> sh: line 1: 1: Bad file descriptor
>>
>> I know the path is OK because the file /usr/tmp/tmp.kPCvVa *IS*
>> created, but
>> it has a size of zero.
>
> the shell handles the redirection and creates the output file so its
> not really an indicator that your path is ok. its a bad idea to just
> call 'date' and not give the full path since some user program called
> date (and someone somwhere has probably done this) would interfere
> with proper behavior.
For this particular case, you are most likely correct, and it's the
raw "date" that's not being correctly interpreted in his code.
The system() library routine operates by doing a:
execl( "/bin/sh", "-c", "date >/usr/tmp/tmp.kPCvVa", NULL);
_exit(127); /* not reached normally */
Since he is getting back what he is getting back (256 - btw, the
correct way to decode this is using the macros used by waitpid() - see
the man page), then it's most likely a bad fd.
I expect that either "date" is not in the default shell path, or he is
invoking this as root (in which case, security dictates that his path
be cleaned out on him by the shell program), or his default path is
bogus, or he has built and replaced /bin/sh with his own code, or
linked it to another sell program, other than the MacOS X default,
which is a specifically modified "bash".
Probably setting the "date" to "/bin/date" instead would fix this: The
bad fd the shell is complaining about is likely the fd in the fread()
of the popen() of the date command, built into the shell, and the
difference is whether or not stack pages contain "bad garbage" or
"good garbage" in the shell itself (as Justin Walker pointed out might
be the case).
Note that if he is running this program as root, and there are local
accounts, it would be rather trivial to get root on the machine as an
ordinary unprivileged user account using this program as is...
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden