On Thursday, September 16, 2004 18:23:00 +0200 Frank Bagehorn <[EMAIL PROTECTED]> wrote:

If you are running TrendMicro ServerProtect for Linux on a machine and
real-time scanning is turned on, AFS will no longer start.
The reason has to do with the sym table look ups that AFS does. In
real-time scanning SPLX will mediate sys_table calls, but AFS circumvents
that and gets lost.
I know that in the long-run the sys_table calls will vanish from the AFS
code, so I don't know if it's worth to do anything about it.
Anyway, here is the response that we got from TrendMicro about their
investigation on the problem:

Ew. But I guess we can't complain, since we _also_ hook the syscall table. A couple of comments that may help you:


First, note that you probably _should_ start AFS (or at least load the AFS kernel module) before turning on SPLX's scanning, so that it gets to mediate user processes' calls to our setgroups() wrapper instead of our wrapper's calls to the real syscall. Otherwise the behaviour may not be what you expect.


Second, note that if you patch your kernel so that sys_call_table is exported (and then recompile OpenAFS against the patched kernel), we no longer have to scan for the syscall table, and the code that SPLX's traps break will no longer be relevant.

Finally, if you run a new enough OpenAFS (1.3.70 should be sufficient), AFS will start and work even if the scan fails to find the syscall table. For this to work, you must be running both a new cache manager (libafs.o) and all new client utilities (particularly afsd and fs, but also anything that uses your tokens to talk to servers), because it works by using an alternate interface that all the utilities need to know about. Also be aware that the mechanism that prevents you losing your PAG when setgroups() is called will not work when we are unable to patch the syscall table.

-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA

_______________________________________________
OpenAFS-devel mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-devel

Reply via email to