linux-kernel - sys_paccept: disable paccept() until API design is resolved

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-next>] [day] [month] [year] [list]

Message-ID: <48CFA10D.2010106@gmail.com>
Date:	Tue, 16 Sep 2008 14:05:33 +0200
From:	Michael Kerrisk <mtk.manpages@...glemail.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	David Miller <davem@...emloft.net>,
	Davide Libenzi <davidel@...ilserver.org>,
	Alan Cox <alan@...hat.com>,
	Ulrich Drepper <drepper@...hat.com>,
	Jakub Jelinek <jakub@...hat.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	netdev <netdev@...r.kernel.org>,
	Roland McGrath <roland@...hat.com>,
	Oleg Nesterov <oleg@...sign.ru>, Christoph Hellwig <hch@....de>
Subject: sys_paccept: disable paccept() until API design is resolved

Andrew,

The patch below disables the new sys_paccept() for now.  Please
apply for 2.6.27-rc, so that we do not release this API into
the wild before a conclusion has been reached about its design.

The reasons for disabling paccept() are as follows:

* The API is more complex than needed.  There is AFAICS no demonstrated
   use case that the sigset argument of this syscall serves that
   couldn't equally be served by the use of pselect/ppoll/epoll_pwait +
   traditional accept().  Roland seems to concur with this opinion
   (http://thread.gmane.org/gmane.linux.kernel/723953/focus=732255).
   I have (more than once) asked Ulrich to explain otherwise
   (http://thread.gmane.org/gmane.linux.kernel/723952/focus=731018),
   but he does not respond, so one is left to assume that he doesn't
   know of such a case.

* The use of a sigset argument is not consistent with other I/O APIs
   that can block on a single file descriptor (e.g., read(), recv(),
   connect()).

* The behavior of paccept() when interrupted by a signal is IMO
   strange: the kernel restarts the system call if SA_RESTART was set
   for the handler.  I think that it should not do this -- that it
   should behave consistently with paccept()/ppoll()/epoll_pwait(),
   which never restart, regardless of SA_RESTART.  The reasoning here
   is that the very purpose of paccept() is to wait for a connection
   or a signal, and that restarting in the latter case is probably
   never useful.  (Note: Roland disagrees on this point, believing
   that rather paccept() should be consistent with accept() in its
   behavior wrt EINTR
   (http://thread.gmane.org/gmane.linux.kernel/723953/focus=732255).)

I believe that instead, a simpler API, consistent with Ulrich's
other recent additions, is preferable:

accept4(int fd, struct sockaddr *sa, socklen_t *salen, ind flags);

(This simpler API was originally proposed by Ulrich:
http://thread.gmane.org/gmane.linux.network/92072)

If this simpler API is added, then if we later decide that the sigset
argument really is required, then a suitable bit in 'flags' could
be added to indicate the presence of the sigset argument.

At this point, I am hoping we either will get a counter-argument
from Ulrich about why we really do need paccept()'s sigset argument,
or that he will resubmit the original accept4() patch.

Cheers,

Michael

Signed-off-by: Michael Kerrisk <mtk.manpages@...il.com>

--- linux-2.6.27-rc6/net/socket.c.orig	2008-09-16 12:38:15.000000000 +0200
+++ linux-2.6.27-rc6/net/socket.c	2008-09-16 13:07:51.000000000 +0200
@@ -1511,6 +1511,7 @@
  	goto out_put;
  }

+#if 0
  #ifdef HAVE_SET_RESTORE_SIGMASK
  asmlinkage long sys_paccept(int fd, struct sockaddr __user *upeer_sockaddr,
  			    int __user *upeer_addrlen,
@@ -1564,6 +1565,7 @@
  	return do_accept(fd, upeer_sockaddr, upeer_addrlen, flags);
  }
  #endif
+#endif

  asmlinkage long sys_accept(int fd, struct sockaddr __user *upeer_sockaddr,
  			   int __user *upeer_addrlen)
--
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/