On 29 Oct (14:58:44), Nick Mathewson wrote: > On Tue, Oct 29, 2013 at 2:38 PM, David Goulet <dgoulet@xxxxxxxxx> wrote: > > > To be honest, I am not sure what's the right fix here or if there is any > > way to lookup the symbol in a "special" way that would help here. Any > > idea or questions are VERY welcome :). > > My first thought -- and I don't know how good it is -- is that perhaps > you could just *not* look at syscalls that occur during the dlsym > calls that you launch? In other words, disable the syscall override if > the current thread is already inside the dlsym() call inside your > syscall override. That would work if there is a way I can "differ" the hijack of the syscall symbol... Unfortunately, this is done at linking time thus during run time, the syscall symbol is already hijacked by torsocks. Let say we don't try to lookup the syscall symbol, the issue is that the original syscall libc pointer will NOT exists within torsocks code so we can't handle call to syscall() because we can't route it to libc. :S It's really that we get in a kind of "infinite loop" where dlsym calls syscall that calls dlsym and so on. But in the first place, we at least need the libc syscall symbol so we can handle them. David > > Would that work? What would it break, if anything? > -- > Nick > _______________________________________________ > tor-dev mailing list > tor-dev@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev