In article <Pine.SOL.4.44.0205161004190.12096-100000@???>,
Philip Hazel <ph10@???> wrote:
>On Wed, 15 May 2002, Jeremy C. Reed wrote:
>
>> I read that on a NetBSD system, Exim 4.04 caused:
>>
>> set{u,g}id pid 17149 (exim-4.04-1) was invoked by uid 104 ppid 209
>> (exim-4.04-1) with fd 0,1,2 closed
>
>That's probably true. So what? Exim is coded like that. The daemon
>closes down all unwanted fds. If it then forks and re-execs to do a
>delivery, they won't exist.
It's probably better to open(/dev/null) and dup that to fds 0,1,2
Something like
fd = open("/dev/null", O_RDWR);
dup2(fd, 0); dup2(fd, 1); dup2(fd, 2);
if (fd > 2) close(fd);
>> ... Some programs are set-user-id or set-group-id, and therefore run with
>> increased privileges. If such a program is started with some of the
>> stdio file descriptors closed, the program may open a file and
>> inadvertently associate it with standard input, standard output, or
>> standard error. The program may then read data from or write data to the
>> file inappropriately.
>
>What the heck does that mean? If a program opens a file and reads/writes
>it, what does it matter what the value of the file decscriptor is? Maybe
>there are programs whose stupidity I'm too stupid to conceive of... :-)
Say for example that you open a spool file in exim and it happens
to get filedescriptor 2
open("/var/spool/exim/whatever") = 2
Now some code in exim, or a library function (more likely) by accident
does a fprintf(stderr, "NIS: cannot bind to server\n"). Where do you
think that output ends up ?
I've actually seen things like error messages in /etc/mtab because
of this (where mount was started with fds 0/1/2 closed).
Mike.
--
"Insanity -- a perfectly rational adjustment to an insane world."
- R.D. Lang
