Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Markus E L <ls-ocaml-2006@m-e-leypold.de>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Closing all open file descriptors
Date: Sat, 15 Sep 2007 16:16:39 +0200	[thread overview]
Message-ID: <5fps0k9fp4.fsf@hod.lan.m-e-leypold.de> (raw)
In-Reply-To: <1189852990.46ebb73e7edc3@webmail.in-berlin.de> (Oliver Bandel's message of "Sat, 15 Sep 2007 12:43:10 +0200")


Oliver Bandel wrote:

> Zitat von Erik de Castro Lopo <mle+ocaml@mega-nerd.com>:
>
>> Oliver Bandel wrote:
>>
>> > If you think you need all this for your daemon,
>> > I ask: why do you think you need it? If you write it, you have
>> > full control over all files you open
>>
>> No, thats not right. I can write a program, that opens a bunch
>> of file descriptors, and then exec his program and his program
>> will inherit all open file descritors.
>
> Yes, that's correct.
> But you (as the programmer) have the control (by design)
> about how to handle that case.

Let's assume (as an example) I'm starting a demon / background process
by clicking on an icon in a desktop environment. Which file
descriptors are open when the demon starts executing? Would I be
expected to patch the desktop to ensure that they aren't? Or will I
have to rely on a rather undocumented bit of the desktop software's
behaviour (perhaps subject to change) to guarantee my demons security.

This sucks on so many levels. My position is, if there is something
you inherit or can create in your process there must also be a way to
browse/index/enumerate what you inherited/created. So, yes, there
should be a enumerate_my_open_descriptors() even in POSIX. If it it
isn't it has to be reinvented in a platform specific way on every
platfrom where this is possible (e.g. under Linux using
/proc/self/fd), to get a better programming environment.

> If you have all your open descriptors in a list,
> you can close them after a fork.

And if you inherit them unkknowingly, you're lost.


> In C, with fcntl, there is a possibility to close files
> on an exec automatically with the close-on-exec flag.

This is aboout what a parent does whom one possibly doesn't control.

Regards -- Markus


  parent reply	other threads:[~2007-09-15 14:11 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-13 22:56 Dave Benjamin
2007-09-14  1:04 ` [Caml-list] " Erik de Castro Lopo
2007-09-14  6:35   ` Dave Benjamin
2007-09-14  6:48     ` Erik de Castro Lopo
2007-09-14  7:32       ` Dave Benjamin
2007-09-14  6:33 ` David Allsopp
2007-09-14  6:41   ` Dave Benjamin
2007-09-14 10:54     ` Andre Nathan
2007-09-14 10:00   ` Mattias Engdegård
2007-09-14 20:31     ` Dave Benjamin
2007-09-14 21:52       ` Oliver Bandel
2007-09-14 22:12         ` Markus E L
2007-09-15  9:15           ` Oliver Bandel
2007-09-15  9:26             ` Erik de Castro Lopo
2007-09-15 10:43               ` Oliver Bandel
2007-09-15 11:36                 ` Mattias Engdegård
2007-09-15 11:57                   ` Oliver Bandel
2007-09-15 14:27                     ` Markus E L
2007-09-15 12:16                   ` Oliver Bandel
2007-09-15 14:29                     ` Markus E L
2007-09-15 18:04                       ` skaller
2007-09-15 14:17                   ` Markus E L
2007-09-15 14:16                 ` Markus E L [this message]
2007-09-15 15:58                   ` Eric Cooper
2007-09-15 16:17                     ` Markus E L
2007-09-15 18:33                       ` skaller
2007-09-15 17:44                   ` skaller
2007-09-14 10:10 ` Gerd Stolpmann
2007-09-14 11:56 ` Oliver Bandel
2007-09-17 11:00 ` Ville-Pertti Keinonen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5fps0k9fp4.fsf@hod.lan.m-e-leypold.de \
    --to=ls-ocaml-2006@m-e-leypold.de \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox