| 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
| ||
|
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/
Powered by blists - more mailing lists