linux-kernel - Re: [PATCHv2 4/4] first use of sys

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: <alpine.DEB.0.9999.0711161003310.15441@twinlark.arctic.org>
Date:	Fri, 16 Nov 2007 10:08:41 -0800 (PST)
From:	dean gaudet <dean@...tic.org>
To:	Ulrich Drepper <drepper@...hat.com>
cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	mingo@...e.hu, tglx@...utronix.de, torvalds@...ux-foundation.org
Subject: Re: [PATCHv2 4/4] first use of sys_indirect system call

you know... i understand the need for FD_CLOEXEC -- in fact i tried 
petitioning for CLOEXEC options to all the fd creating syscalls something 
like 7 years ago when i was banging my head against the wall trying to 
figure out how to thread apache... but even still i'm not convinced that 
extending every system call which creates an fd is the way to do this.  
honestly i think there should be a per-task flag which indicates whether 
fds are by default F_CLOEXEC or not.  my reason:  third party libraries.

i can control all my own code in a threaded program, but i can't control 
all the code which is linked in.  fds are going to leak.

if i set a per task flag then the only thing which would break are third 
party libraries which use fork/exec and aren't aware they may need to 
unset F_CLOEXEC.  personally i'd rather break that than leak fds to 
another program.

but hey i'm happy to see this sort of thing is finally being fixed, 
thanks.

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