linux-kernel - Re: [patch 7/8] fdmap v2

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]

Message-Id: <B8B9EC80-2E36-433E-87EB-5B31FF42FBCF@mac.com>
Date:	Thu, 7 Jun 2007 07:59:47 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Ulrich Drepper <drepper@...hat.com>,
	Davide Libenzi <davidel@...ilserver.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, Eric Dumazet <dada1@...mosbay.com>
Subject: Re: [patch 7/8] fdmap v2 - implement sys_socket2

On Jun 07, 2007, at 06:04:32, Alan Cox wrote:
>> continuous allocation are part of the API.  It's required by POSIX  
>> and provided by Unix since the early days.  There are entire code  
>> bases out there which depend on this assumption.  Linking with  
>> code like this, before or after the new version controlled symbol  
>> is introduced, will break it.
>
> If your linker is doing its job then you won't be able to link them  
> together because they have incompatible assumptions. Not exactly  
> rocket science even if it is done a little differently to the usual  
> symbol compatibility tests.

No, there is a fundamental problem with "solving" this via linking.   
Many programs need the continuous FD allocation space, but then have  
tendancies to do things like:

   int i;
   for (i = 0; i < 1024; i++)
           if (i != comm_sock && i != server_sock)
                   close(i);

Yes I have seen many such programs, it seems to be a pretty standard  
idiom.

On the other hand, that makes it completely impossible for libraries  
to reliably use FDs behind the application's back; they might get  
closed on you at any time without warning.  One such library is  
glibc; it would really like to be able to use file-descriptors behind  
the back of the rest of userspace to implement certain functionality:
   http://www.mail-archive.com/linux-kernel@vger.kernel.org/ 
msg163522.html

Likewise there are a massive group of other libraries (especially  
user-interface and server related ones) that would really like to  
have support for creating file-descriptors without the top-level  
application closing them randomly (like several shells seem to).

Cheers,
Kyle Moffett

-
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/