jt@toerring.de (Jens Thoms Toerring) writes:
> Rainer Weikusat <rainer.weikusat@sncag.com> wrote: 

[...]
[vbcol=seagreen] 
> 
>
> Sorry, but I've got to disagree: if the caller exec()s a new process
> (s)he must be aware that file descriptors gets inherited by the new
> process as it has always been part of what you have to take into
> consideration when using exec(). And since this is a PERL module
> Connie is writing it's normally not even an issue anyway since in
> PERL all the files will have the close-on-exec flag already set
> (except 0, 1 and 2), so they won't leak to what the module exec()s
> - unless the caller for some reasons of it's own un-set it and then
> the writer of a module should not assume to know better than the
> caller.

This depends on the purpose of the executed program. If it is totally
internal, there is no reason that the caller, which eventually
un-FD_CLOEXEC'd something even knew that the descriptor that should
have been passed to something executed directly on behalf of the
caller is going to leak through to a second program.

> It only could become an issue if someone exec()s a Perl
> script using the module e.g. from a C program, but then I would
> stand by my opinion that the writer of such a program is required
> to know what (s)he's doing.

In other words (as I have written above), it is your opinion that
'having someone to blame' is a sufficient replacement for 'having
something that works'. This is something I disagree with.

> Actually, I don't appreciate it if I try to use some tool and find
> that it tries to be too clever and insists on keeping me from making
> "mistakes" (typically not even mentioning it in the documentation)
> that aren't mistakes at all but well documented methods of getting
> things done.

I don't understand how this general statement about policy-enforcing user
interfaces could possibly relate to 'user-transparent execution of
programs to accomplish defined tasks'.

[ Post a follow-up to this message ]