Is there a way to run an arbitrary command under a specified remapping of path names, i.e. so that when the command opens file named A it would instead open file named B?
Essentially, I'd like to intercept the open() system call and modify its argument.
I've seen references on the web for techniques for doing that, but is there a
simple standalone utility that will run a given command under a given file name remapping?
Thanks for help,
ilya
There's not really a simple standalone utility for that, no. Besides -- you haven't even said what your system is.
There might be smarter ways to do whatever you're trying to accomplish than intercepting system calls to make your application open the wrong files.
Thanks for looking at my question.
The system is x86_64 GNU/Linux, CentOS.
As for other ways, none of them would be as general. This would be a once-and-for-all solution.
Is there some technical reason such a utility doesn't exist, or is it just the lack of demand?
Thanks,
ilya
It's unportable, and insecure -- arguably operating through a security hole that some think shouldn't be permitted. It introduces the possibility for new and interesting bugs inside the open() call itself. And if making system calls lie to the application seems like the best solution, it's either a really badly designed application, or an application restriction that wasn't intended to be circumvented, or just a solution that needs more thinking through. There's almost always a better way, even if it means fixing the broken app.
Also consider the sheer number of system calls that might need trapping. Is open() really the only system call your application needs? what about stat(), unlink(), and the dozens of other system calls that need a filename. It's not as "easy" as it looks on first blush. I tried writing something like this to overload gettimeofday() to make programs run "slower". It worked, sort of, but we found more and more time-related calls which needed to be trapped to work right. Eventually I realized I needed to trap and deal with the hardcoded asm timing-related things in pthreads itself, and gave up. Stuff that alters how kernel calls operate that drastically belongs in the kernel.
One after-the-fact fix I see done with it is libkeepalive, to set TCP keepalive intervals by default whenever a program calls socket(). Since nearly no programs have the ability to do so themselves, and you'd hardly want to set keepalives on every single socket in your system, it can be handy. It's also relatively easy, since it only needs to trap exactly one system call -- socket().
And you haven't explained what your actual goal is, either. Until you do I'm not convinced this would be the best way.