Re: MoreAuthSample
Re: MoreAuthSample
- Subject: Re: MoreAuthSample
- From: Jim Luther <email@hidden>
- Date: Tue, 21 Mar 2006 07:53:42 -0800
You NEVER want to just close STDIN_FILENO, STDOUT_FILENO, or
STDERR_FILENO because those file descriptors could then be reused for
something else, and then any reads or writes to those file descriptor
numbers by code *thinking* is it using STDIN_FILENO, STDOUT_FILENO, or
STDERR_FILENO would reading or writing to the wrong file or socket.
If you want to disable STDIN_FILENO, STDOUT_FILENO, or STDERR_FILENO,
you should redirect them to /dev/null using code like this:
{
/* redirect standard input, standard output, and standard error
to /dev/null */
int fd;
fd = open(_PATH_DEVNULL, O_RDWR, 0);
if (fd != -1)
{
(void)dup2(fd, STDIN_FILENO);
(void)dup2(fd, STDOUT_FILENO);
(void)dup2(fd, STDERR_FILENO);
if (fd > 2)
{
(void)close(fd);
}
}
}
- Jim
On Mar 21, 2006, at 4:25 AM, Andy Cave wrote:
Hi Quinn,
Absolutely correct - the application in question closes stdin/stdout
but leaves stderr open. Then it does a system call, which invokes
the auth app/tool. The system call does a fork/exec which dups
stderr as fd 0. But there is no fd 1 or 2. auth tool then calls AEWP
which fails silently - returns a 0!! I found this out because the
only way to debug this was to add fprintf statements in the code.
When I added one purely by luck before the AEWP call, it suddenly
worked, and that's when I worked out what was going on (and 'proved'
it by fixing it). My 'fix' was exactly as you say - open /dev/null
and map it to 0, 1 & 2 (just in case all three are required).
I agree it's an unusual thing to do. Don't ask me why!!
The bug wasted a good couple of days of my time, as I went round in
loops checking everything else in more and more detail each time and
going crazy, which was rather a pain.
Regards,
I will file a bug.
Andy.
----- Original Message ----- From: "Quinn" <email@hidden>
To: <email@hidden>
Sent: Tuesday, March 21, 2006 11:55 AM
Subject: Re: MoreAuthSample
At 21:32 +0000 20/3/06, Andy Cave wrote:
However, I think I have one more previously unknown issue with
AuthorizationExecuteWithPrivileges which is not dealt with in your
code. If the file descriptors for stdin and stdout have been
closed, then AuthorizationExecuteWithPrivileges silently fails
(!!). [...]
Question is, can you confirm that this is a bug in AEWP and not
covered in your code?
Let me get this straight. You're saying that, if file descriptors
0 and 1 are closed in the /application/, AEWP fails silently?
Interesting. I've not encountered it before. Closing the standard
file descriptors in an application is quite unusual. [It's common
to do in a daemon, but daemons don't go around calling AEWP.]
Looking at the code, it seems that both MoreAuthSample and
Authorization Services suffer from problems with 0 and 1 are
closed. Code like this:
err = socketpair(..., fds);
err = dup(fds[0], 0);
err = dup(fds[1], 1);
runs into trouble if fds contains low numbers.
Traditionally, one does not close these low numbered descriptors;
instead, you open /dev/null and dup it down on to them.
Still, smells like a bug to me. Please feel free to file it.
<http://developer.apple.com/bugreporter/>
[In general DTS asks developers to file their own bugs because it
emphasises that the issue is affecting real developers. Also, it
has the added benefit that you can track the bug's status yourself.]
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/
>
Apple Developer Technical Support * Networking, Communications,
Hardware
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden