Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!nosc!ucsd!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: syscall(2) function
Keywords: syscall, not system calls
Message-ID: <9757@smoke.BRL.MIL>
Date: 1 Mar 89 06:46:56 GMT
References: <3740@ucdavis.ucdavis.edu> <8984@alice.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 19

In article <8984@alice.UUCP> debra@alice.UUCP () writes:
>2) a new routine "open()" is written, which modifies the "D.systemXXXX"
>   into "D.system/XXXX", and then calls syscall() with the right
>   parameters to do the real open(). By having your own open() routine
>   there is no way to access the real open() system call any more, so
>   they use syscall instead.

There is a danger here that you need to be aware of.
Quite possibly some of the application code opens files via calls
to fopen() rather than directly using open().
The above trick has worked so far because UNIX fopen() eventually
invokes the open() function in the C library.
In the near future, it is probable that UNIX fopen() will instead
invoke a function called __open() or some such;
this is required for compliance with the (forthcoming) ANSI C standard.
(There are actually some ways around this but the simplest
implementation is as I've just described.)
Therefore the application will no longer have all its file-opening
attempts intercepted by your "wrapper" around the OPEN system call.