From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6419 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Add login_tty Date: Sat, 1 Nov 2014 23:07:08 +0100 Message-ID: <20141101220708.GI10829@port70.net> References: <20140825185756.GA6077@euler> <20140825224333.GX12888@brightrain.aerifal.cx> <20140826165627.GA1208@euler> <20141031161907.GD22465@brightrain.aerifal.cx> <20141101211523.GA13145@euler> <20141101214503.GK22465@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1414879649 18199 80.91.229.3 (1 Nov 2014 22:07:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 1 Nov 2014 22:07:29 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6432-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 01 23:07:22 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XkgpO-0003P5-1x for gllmg-musl@m.gmane.org; Sat, 01 Nov 2014 23:07:22 +0100 Original-Received: (qmail 15851 invoked by uid 550); 1 Nov 2014 22:07:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 15843 invoked from network); 1 Nov 2014 22:07:20 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20141101214503.GK22465@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:6419 Archived-At: * Rich Felker [2014-11-01 17:45:03 -0400]: > > > > I still don't understand how dup2 can fail when fd 0/1/2 are not open in > > the parent. AFAIU, limits on the number of open fds are imposed by an > > upper bound on the value of any fd. For the dup2 calls we know that the > > newfds are certainly within the limits. > > Indeed, looking at the kernel code, I don't see any error paths where > this operation could fail. I had figured some allocations might be > needed to represent the new fd in the fd table, but it seems not. So > the current code is probably unnecessary. > i think with seccomp syscall filtering anything can fail although libc probably dont have to take that into account