linux-kernel - Re: dup2() vs dup3() inconsistency when

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 10 Oct 2008 15:15:14 +0200
From:	"Michael Kerrisk" <mtk.manpages@...glemail.com>
To:	"Bernd Petrovitsch" <bernd@...mix.at>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	"Ulrich Drepper" <drepper@...hat.com>,
	"Al Viro" <viro@...iv.linux.org.uk>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: dup2() vs dup3() inconsistency when

On Fri, Oct 10, 2008 at 3:02 PM, Bernd Petrovitsch <bernd@...mix.at> wrote:
> On Fri, 2008-10-10 at 14:15 +0200, Michael Kerrisk wrote:
>> On Fri, Oct 10, 2008 at 2:09 PM, Bernd Petrovitsch <bernd@...mix.at> wrote:
>> > On Fri, 2008-10-10 at 07:04 +0200, Michael Kerrisk wrote:
>> > [....]
>> >> Well, as long as we are fixing the dup3() interface in the way that Al
>> >> and Ulrich have suggested, what about another fix:
>> >>
>> >> give an error if newfd is already open, thus forcing the user to do an
>> >> explicit close
>> >>
>> >> ?
>> >>
>> >> This silent close in dup2() is an implementation blemish.  Why not eliminate it?
>> >
>> > Apart from the usual "do not break almost all existing apps" killer
>> > reason: The alternative is that people will simply add a "close(newfd)"
>> > everytime before "dup2(oldfd,newfd)" since close() is harmless on a
>> > non-open fd.
>>
>> Bernd,
>>
>> I think you've missed the point.  The idea is not to change to dup2(),
>
> That may well be. So the "eliminate it" apparently doesn't mean
> "eliminate it in dup2()".

Right.

>> but to eliminate the blemish in its design in the new dup3() (since we
>> have alrady eliminated one other blemish).
>
> FWIW I consider the automatic close() in dup2() a feature (if only that
> it avoids an additional system call).

Exploiting this "feature" can hide real errors that would be detected
if one does an explicit close().  (See the dup2 man page.)

Cheers,

Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/