linux-kernel - Re: [RFC PATCH] vfs: new open(2) flag to open filesystem node

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

Message-ID: <alpine.LFD.2.01.0907060858560.3210@localhost.localdomain>
Date:	Mon, 6 Jul 2009 08:59:17 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ulrich Drepper <drepper@...il.com>
cc:	Miklos Szeredi <miklos@...redi.hu>, dhowells@...hat.com,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	hch@...radead.org, viro@...iv.linux.org.uk, adilger@....com,
	alan@...rguk.ukuu.org.uk, akpm@...ux-foundation.org,
	mtk.manpages@...il.com
Subject: Re: [RFC PATCH] vfs: new open(2) flag to open filesystem node



On Sun, 5 Jul 2009, Ulrich Drepper wrote:

> On Sun, Jul 5, 2009 at 17:40, Linus
> Torvalds<torvalds@...ux-foundation.org> wrote:
> > O_SEARCH is only meaningful for directories. For anything else, it's not
> > at all POSIX - it's expressly defined to be "undefined".
> 
> And this is why there is the differentiation with O_EXEC.  Yes, i
> didn't mention it in the last email.  But I mentioned it when it came
> up the first time.
> 
> I don't say this is indeed what is wanted/needed here.  But there are
> IMO some similarities and I think implementing O_SEARCH and O_EXEC is
> desirable.  If it means completely different implementations from te
> proposed O_NODE, so be it.  But my gut tells me there is some overlay.

I suspect that what we _could_ possibly do is to have something like 
O_NODE, and after that - if the semantics (for directories) match what 
O_SEARCH/O_EXEC wants, we could just do

	#define O_SEARCH O_NODE

but my point is that we should _not_ start from O_SEARCH and make that the 
"core" part, since its semantics are badly defined (undefined) to begin 
with.

Put another way: it's better to start with something that is well-defined 
(for us), and then say "in the special case of directories, this becomes 
the same thing as O_SEARCH", than start with something that is defined 
only for directories, and then say "ok, the behavior for other things is 
undefined, so we could hijack it for our own uses".

		Linus
--
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/