linux-kernel - Re: [PATCH] paccept, socket, socketpair w/flags

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

Date:	Mon, 28 Apr 2008 16:51:21 +0200
From:	"Michael Kerrisk" <mtk.manpages@...glemail.com>
To:	"Ulrich Drepper" <drepper@...hat.com>
Cc:	"Michael Kerrisk" <mtk.manpages@...il.com>,
	"Alan Cox" <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	akpm@...ux-foundation.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH] paccept, socket, socketpair w/flags

On Mon, Apr 28, 2008 at 4:13 PM, Ulrich Drepper <drepper@...hat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Kerrisk wrote:
> > This is ugly.  Why invent a diffent set of flags here.  I agree with
> > your earlier statement that new syscalls would be cleaner.
>
> Don't lay words in my mouth.  I do think that different flags are
> needed.

Okay -- to some extent I seem to have misunderstood you.  I'll step
back a little and start again.

You have said it would be cleaner to have new syscalls for socket()
and socketpair().  I understand your reasoning for that to be that
doing so is cleaner than overloading the type argument of the existing
versions of these syscalls.  I agree.  So, since you are adding new
syscalls for all of the other interfaces, why not do it for these two
syscalls also?

> The name of the flag must indicate what it is for and you don't
> want to mix flags with different prefixes for the same flags parameter.
>  Not introducing separate flags would mean all the functions would have
> to accept the same set of flags which will sooner or later create
> problems.  I really don't see the problem here.
>
>
> > then *please* let's go the hwole way cleanly, and have new syscalls
> > also for socketpair() and socket(), and make all of the new syscalls
> > use the same flags.
>
> Hell, no, that's worse than everything else proposed.  We don't have the
> luxury to have a separate parameter to indicate close-on-exec or not.
> For efficiency it has to be a multi-purpose flags parameter and the
> flags each syscall takes are different since the functionality is different.

Okay -- I see your point (and I didn't read your patches closely
enough).  However, the rationale for the implementations proposed to
date isn't very clear.  So far we have the following new flags:

timerfd_create() -- TFD_CLOEXEC
signalfd4() -- SFD_CLOEXEC
eventfd2() -- EFD_CLOEXEC
epoll_create2() -- EPOLL_CLOEXEC
open() (and openat()), dup3() -- all use O_CLOEXEC
socketpair(), socket(), paccept -- all use SOCK_CLOEXEC
pipe2() -- to be determined
inotify_init2() -- to be determined

It would help if you laid out your reasoning for creating distinct
flags for some syscalls but not others.  For example, is the
assumption here that socketpair(), socket(), and paccept() will always
use the same set of flags?  If so, what makes that group special with
respect to your arguments about the need for separate flags for each
syscall?
--
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/