mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Add login_tty
Date: Thu, 4 Sep 2014 17:33:34 -0400	[thread overview]
Message-ID: <20140904213334.GF23797@brightrain.aerifal.cx> (raw)
In-Reply-To: <20140904212159.GG10361@port70.net>

On Thu, Sep 04, 2014 at 11:22:00PM +0200, Szabolcs Nagy wrote:
> * Felix Janda <felix.janda@posteo.de> [2014-08-26 18:56:28 +0200]:
> > --- /dev/null
> > +++ b/src/misc/login_tty.c
> > @@ -0,0 +1,14 @@
> > +#include <utmp.h>
> > +#include <sys/ioctl.h>
> > +#include <unistd.h>
> > +
> > +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


  reply	other threads:[~2014-09-04 21:33 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-25 18:57 Felix Janda
2014-08-25 22:43 ` Rich Felker
2014-08-26 16:56   ` Felix Janda
2014-08-29 18:44     ` Felix Janda
2014-09-04 21:22     ` Szabolcs Nagy
2014-09-04 21:33       ` Rich Felker [this message]
2014-09-04 22:31         ` Justin Cormack
2014-09-05 17:23       ` Felix Janda
2014-09-05 17:29         ` Rich Felker
2014-09-05 18:52           ` Felix Janda
2014-10-31 16:19     ` Rich Felker
2014-11-01 21:15       ` Felix Janda
2014-11-01 21:45         ` Rich Felker
2014-11-01 22:07           ` Szabolcs Nagy
2014-11-01 22:27           ` Felix Janda
2014-11-01 22:43             ` Rich Felker
2014-11-01 22:56               ` Felix Janda
2014-11-02  0:09                 ` Rich Felker
2014-11-02 14:19                   ` Felix Janda
2014-11-02 16:28                     ` Rich Felker
2014-11-02 18:56                       ` Felix Janda
2014-11-02 22:28                         ` Rich Felker
2014-11-03 18:29                           ` Felix Janda
2014-12-21  0:58                             ` Rich Felker
2014-12-21  1:15                               ` Rich Felker
2014-12-21  1:38                               ` Rich Felker
2014-12-21  2:59                                 ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140904213334.GF23797@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).