On Tue, 2006-10-17 at 12:09 -0400, Paul Moore wrote: > I just spent a few minutes looking at splice() and there are two things I am > concerned about (anybody have any others?): > > 1. Application splice()'ing a socket with a context matching the domain to a > socket created a setsockcreatecon() context. This could be an issue, but > since > setsockcreatecon() is restrcited I wonder if it would be a problem in > practice.
I'm not 100% sure that splice() can do TCP -> TCP splices. The idea behind the API is that everything goes through a pipe(). So you'd have: net IN -> pipe -> net OUT ...where the pipe acts in the same way to a user space buffer (and you'd need two splice calls ... one acts as the read and one as the write). I'd heard they'd done an "internal pipe" for disk IO -> network so that splice() could be directly called instead of sendfile(). > 2. Similar to #1 but in the case the non-matching socket would be created > through accept() and labeled networking. This is a bit more scary as this has > the potential to be more widespread than #1. However, if Venkat is right > about > being able to deny connections at the connection request level then this may > not > be an issue. How would you treat read+write here? Ie. if splice fails the app. is going to go into a "read net IN" "write net OUT" loop. I think you have to treat splice the same way. -- James Antill <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
-- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
