linux-kernel - Re: [patch 7/8] fdmap v2

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: <alpine.LFD.0.98.0706091623090.20321@woody.linux-foundation.org>
Date:	Sat, 9 Jun 2007 16:33:31 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@....linux.org.uk>
cc:	Kyle Moffett <mrmacman_g4@....com>,
	Ulrich Drepper <drepper@...hat.com>,
	Davide Libenzi <davidel@...ilserver.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Theodore Tso <tytso@....edu>,
	Eric Dumazet <dada1@...mosbay.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [patch 7/8] fdmap v2 - implement sys_socket2

On Sat, 9 Jun 2007, Al Viro wrote:
> 
> Eww...  Idea of pipe(2) taking flags as argument...

Right. That was one of the patches, and it was one that I said was too 
damn ugly to live.

So I instead suggested the alternate approach of adding a single new 
system call that runs another system call indirectly, with a set of flags 
and/or other behaviour modifications.

And I actually think that's a great idea, because we have *multiple* uses 
of this kind of "run system call with special flags" issues:

 - the whole "async" thing, and as Matt reminded me, this is the perfect 
   interface for also saying "run this system call asynchronously"

 - things like FD_CLOEXEC, but also things like O_NOFOLLOW and O_NDELAY 
   (which currently only "open()" supports, even though it makes sense for 
   a lot of other ops too)

 - extended flags like LOOKUP_NOSYMLINK and LOOKUP_NOMOUNT for any system 
   call that does path lookup (to make it return errors if you *ever* 
   traverse a symlink or a mount-point respectively: security conscious 
   programs tend to want this - think about apache that exports per-user 
   "public_html" stuff, but does *not* want to export /etc, and thus 
   doesn't like following symlinks).

> I don't know if your indirect is a good idea in that respect, actually.
> AFAICS, you are suggesting per-syscall meanings of the flags, so it really
> smells like YAMultiplexor, free for abuse.

Well, the actual _setup_ would be global (ie we would have no per-system 
call actions: we'd just copy the "flags" into the thread 
"system_call_flags" thing).

But yes, different system calls could decide to *interpret* the flags 
differently. Quite frankly, I'd rather have that kind of overloaded flag 
bitmap, than try to create something "extensible". 

That said, I don't think there really will be all that many flags, and we 
could even just decide that the bits have to be totally unique (and simply 
limited to 32 flags). The whole point of the flags, after all, would be 
things that *do* make sense for a whole group of system calls: if that's 
not true, and it's some single-system-call thing, then you might as well 
just always add the new system call itself!

So it makes sense for generic flags (like ASYNC and path lookup rules: not 
every system call takes a path, of course, but it's conceptually still 
pretty damn generic). but it wouldn't really make sense to do for a very 
specific system call - it would be faster and easier to just create the 
new system call in the first place.

		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/