On 22 Oct (16:29:28), intrigeri wrote: > Hi, > > David Goulet wrote (22 Oct 2014 13:22:14 GMT) : > > Yes. That means torsocks detected that the torified process received an > > inet socket from an other process using the fd passing feature of Unix > > socket thus stopped everything since it can't torify that socket. > > Thanks for the explanation :) > > > I thought about a middle groud of simply denying the call and returning > > an error but still printing an error. > > > Let me know if you would be open to try that. I can provide a trivial > > patch quickly for testing. > > I'm not sure what would be best for user experience. > > The problem with aborting the torsocks'ified application altogether is > that it can result in data loss -- right? If that's the case, then > this bug is actually release critical, and indeed the way you're > suggesting seems to be the way to go. In order to have it in Jessie > without needing to go through the unblock request process, we would > have to upload a fix in the next 2 days. > > OTOH, merely returning+printing an error could be confusing, if the > application is poorly written and doesn't check the return value. > I guess that's someone else's problem™, but actually we have to care > a little bit, and I've no idea how widespread such problems can be in > the real world. Any idea?
Poor code is *very* widespread in the world unfortunately... However, application using fd passing are usually a bit more resilient since it's not a trivial feature to use and many errors are possible! I think that once we detect FD passing (if inet), we could stop it, close the passed socket and return something like EACCESS. This is not documented in the man page unfortunately but Linux LSM return that error code if denied (I just confirmed with the kernel code) so I think it would be a good alternative. In a nutshell, cleanup the received socket and return EACCESS? If we agree on that, I can push a patch today! David > > Cheers! > -- > intrigeri
signature.asc
Description: Digital signature
