From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6075 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Add login_tty Date: Thu, 4 Sep 2014 17:33:34 -0400 Message-ID: <20140904213334.GF23797@brightrain.aerifal.cx> References: <20140825185756.GA6077@euler> <20140825224333.GX12888@brightrain.aerifal.cx> <20140826165627.GA1208@euler> <20140904212159.GG10361@port70.net> 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 1409866433 15606 80.91.229.3 (4 Sep 2014 21:33:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Sep 2014 21:33:53 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6088-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 04 23:33:49 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XPef6-0000cD-EH for gllmg-musl@plane.gmane.org; Thu, 04 Sep 2014 23:33:48 +0200 Original-Received: (qmail 26454 invoked by uid 550); 4 Sep 2014 21:33:47 -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 26446 invoked from network); 4 Sep 2014 21:33:46 -0000 Content-Disposition: inline In-Reply-To: <20140904212159.GG10361@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6075 Archived-At: On Thu, Sep 04, 2014 at 11:22:00PM +0200, Szabolcs Nagy wrote: > * Felix Janda [2014-08-26 18:56:28 +0200]: > > --- /dev/null > > +++ b/src/misc/login_tty.c > > @@ -0,0 +1,14 @@ > > +#include > > +#include > > +#include > > + > > +int login_tty(int fd) > > +{ > > + setsid(); > > + if (ioctl(fd, TIOCSCTTY, (char *)0)) return -1; > > + dup2(fd, 0); > > + dup2(fd, 1); > > + dup2(fd, 2); > > + if (fd>2) close(fd); > > + return 0; > > +} > > i recently came across this: > http://lxr.free-electrons.com/source/fs/file.c#L751 > > so dup2 may spuriously fail with EBUSY on linux This can only happen when you're already invoking UB via a call to dup2 where you don't know the dest fd number is already open, and where it might race with open. It's actually not 100% clear to me that this is UB, but I base my claim on the allowance for the implementation to make internal use of file descriptors, explained here: http://austingroupbugs.net/view.php?id=149 Using dup2 where the application does not know it "owns" the dest fd already seems equivalent to calling close on an fd you don't own. In any case, it should not be able to happen in correct programs. Details on the topic may be found here: http://stackoverflow.com/a/24012015/379897 > the current forkpty does not check dup2 either, but i > wonder if it should be > > while(dup2(fd,0)==-1 && errno==EBUSY); > > instead Actually, musl's dup2 already accounts for the issue by looping internally, but I'm thinking we should remove that. POSIX does not forbid dup2 from failing when you do something idiotic like this (actually, like I said, I think it's morally UB), but it does demand that open and dup2 be atomic with respect to each other for regular files, whereas the loop would delay indefinitely a thread calling dup2 on a file descriptor for which another thread is stuck in uninterruptible sleep trying to open (e.g. slow/dead NFS). Any thoughts on whether/how this should be changed? Rich