unlinking / linking functions in a compiled program

unlinking / linking functions in a compiled program

Post by D'Arcy J.M. Ca » Sat, 22 Jun 1991 02:41:33



[Note cross-post and followup - this really isn't a wizard question]


>I need some help with the link editor. What I want to do is find a way
>to ship to my customers my product in binary formated but provide a
>way for them to unlink some of my functions and replace them with
>functions of there own design.

I think you're doing it the hard way.  Why not use libraries?  Write
the program with main renamed to my_main or something, create a library
with all the modules that make up the program then have a short main
which you ship in source form as follows:

    int my_main(int argc, char **argv);
    int main(int argc, char **argv)
    { return(my_main(argc, argv)); }

Now by compiling the above with your supplied library you get your program.
If someone wants to modify it then they simply link in new modules.  The
system will pick them up before the library routines.  They can even add
the new code into the main program if they want to keep it all together.

If you do this you should be careful about global variables.  Be sure to
declare everything static outside of functions if possible.

Quote:>It would be nice but not required if this solution also worked in DOS

Different tools but the same idea.

Note, I am assuming that the user has a development system since they are
designing their own replacement functions however third party libraries
may be a problem from a copyright standpoint.

--

D'Arcy Cain Consulting             |   There's no government
Toronto, Ontario, Canada           |   like no government!
+1 416 424 2871                    |

 
 
 

1. WANTED: A secure kernel `unlink' function.

I'd like to have patch for the kernel... a relatively simple one.  (If any
of you weekend hackers happen to have some time on your hands, maybe you
would consider implementing this.)

In a nutshell, I'd like to have a kernel in which the `unlink' function
actually overwrites (e.g. with zeros) the file being unlinked.

Seems to me that security-minded people who are operating multi-user
systems would appreciate this.

Of course there are bound to be naysayers who will immediately scream
that this would make the system too slow... but I have a suggestion
which could possibly reduce that problem.

Here's the idea....

Implement a kernel `unlink' function which either does or doesn't do
erasing depending upon the setting of some environment variable in
the calling process.

I can imagine two different way to implement this, depending upon what
the sysadmin wants to be the default behavior.

For the paranoid sysadmin, the default behavior would be to erase, and
the kernel would check for NO_ERASE defined in the environment of the
calling process (and if it found that symbol defined, it would NOT
actually do the erasing).

For the relaxed sysadmin, the default would be not to erase files when
unlinking them, but if ERASE is set in the environment of the calling
process, files would be erased as they are unlinked.

Of course, the selection of which default to use (paranoid or relaxed)
would be a kernel build-time option.

In practice, I would guess that the default that most people would
select would be the relaxed default, thus causing erasure of unlinked
files only when specifically requested by the user issuing the `unlink'
request.  (Paranoid users would just set ERASE in their .profile or
their .cshrc files, and then leave it set all of the time.)

Can this sort of stuff be done _outside_ the kernel?  Yes, of course.
But it cannot be done _transparently_ (e.g. to pre-existing binaries
of pre-existing programs) unless it is implemented directly within
the kernel implementation of `unlink'.  (I think that efficiency
concerns would also dictate that this would be best done within the
kernel too, but that is a separate issue.)

If you have comments on this idea, and if you would like me to see them,
please send them to me via E-mail, as I do not normally read this newsgroup.
Thanks.

P.S.  I just realized that (to be _really_ effective) this whole idea
should really be applied not only to `unlink', but also to `truncate'
and `ftruncate' also.
--

-- Ron Guilmette, Roseville, CA -------- Infinite Monkeys & Co. ------------

----------------------------------------------------------------------------

2. winlinux

3. how can i compile and link crypt() function.

4. ppp to Windows NT RAS

5. Functions LOCK & UNLOCK using NAMED PIPES and CREATE & UNLINK

6. Athena widgets

7. POP Email - Yes/No?

8. linking and unlinking

9. linking and unlinking directories

10. how to compile C program using shm functions?