linux-kernel - Re: [PATCH] alternative to sys

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]

Message-ID: <517f3f820804240906k6a701c2et86a4cabd730a8651@mail.gmail.com>
Date:	Thu, 24 Apr 2008 18:06:55 +0200
From:	"Michael Kerrisk" <mtk.manpages@...il.com>
To:	"Alan Cox" <alan@...rguk.ukuu.org.uk>
Cc:	"Ulrich Drepper" <drepper@...hat.com>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	akpm@...ux-foundation.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH] alternative to sys_indirect, part 1

On 4/24/08, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> > You didn't read what I wrote.
>
>
> The feeling is mutual
>
>
>  > For those the implementer must ensure that during the development no
>  > value is used which can conflict with any current and future assigned
>  > value and not with any other development.
>
>
> Kernel socket type values are assigned by the kernel team so that
>  isn't a problem.
>
>
>  > > Every other property of a socket via accept() is inherited from the
>  > > parent. Making one property different would be bizarre and ugly.
>  >
>  > Implementing this would visibly change existing code and it would
>  > actively violate POSIX.  Not a good idea.
>
>
> POSIX has no interface for this new behaviour you propose so that is
>  complete crap. The moment you use one of these features you stepped
>  outside of the POSIX spec - and you know that. If there was an existing
>  standard we wouldn't have a problem.

Alan, I agree with your analysis of the standard on that last para,
but I'm still not convinced that having the behavior inherited from
accept() would be good.  The problem (IIUC) is that after the
accept(), a userland programmer might want to immediately change the
O_CLOEXEC for the descriptor, and there would be the same race there
that this whole thread is about avoiding.

-- 
I'll likely only see replies if they are CCed to mtk.manpages at gmail dot com
--
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/