Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have an application that reads a file. Let's call it processname and the file ~/.configuration. When processname runs it always reads ~/.configuration and can't be configured differently. There are also other applications that rely on "~/.configuration", before and after, but not while processname is running.

Wrapping processname in a script that replaces the contents of ~/.configuration is an option, but I recently had a power outage (while the contents were swapped out), where I lost the previous contents of said file, so this is not desirable.

Is there a way (perhaps using something distantly related to LD_DEBUG=files processname?) for fooling a process into reading different contents when it tries to read a specific file? Searching and replacing the filename in the executable is a bit too invasive, but should work as well.

I know it's possible to write a kernel module that takes over the open() call (https://news.ycombinator.com/item?id=2972958), but is there a simpler or cleaner way?

EDIT: When searching for ~/.configuration in the processname executable I discovered that it tried to read another filename right before reading ~/.configuration. Problem solved.

share|improve this question
2  
This could be done via LD_PRELOAD or FUSE, like with this somewhat similar problem, but I don't know any existing implementation. –  Gilles Jun 29 '13 at 0:38

2 Answers 2

up vote 4 down vote accepted

In recent versions of Linux, you can unshare the mount namespace. That is, you can start processes that view the virtual file system differently (with file systems mounted differently).

That can also be done with chroot, but unshare is more adapted to your case.

Like chroot, you need superuser priviledged to unshare the mount namespace.

So, say you have ~/.configuration and ~/.configuration-for-that-cmd files.

You can start a process for which ~/.configuration is actually a bind-mount of ~/.configuration-for-that-cmd in there, and execute that-cmd in there.

like:

sudo unshare -m sh -c "
   mount --bind '$HOME/.configuration-for-that-cmd' \
                '$HOME/.configuration' &&
     exec that-cmd"

that-cmd and all its descendant processes will see a different ~/.configuration.

that-cmd above will run as root, use sudo -u another-user that-cmd if it need to run as a another-user.

share|improve this answer
    
I think your solution is probably the better of the two given so far (and given what the OP is after, redirecting based on time or the results of a detection process seems iffy to me), but I think they're wanting a single file to show up differently. So they'd probably have to mount it elsewhere and use a symlink, counting on the differing mount points to act as the actual point of redirection. –  Joel Davis Jun 28 '13 at 15:38
1  
@JoelDavis, you can bind-mount any file, not only directory ones. –  Stéphane Chazelas Jun 28 '13 at 16:28
    
TIL. Are there security controls with that, though? I tried it using a subdirectory where I was in (binding from /etc/fstab) and it returned "Not a directory" but I did pretty much the same thing under /test and it worked without issue. –  Joel Davis Jun 28 '13 at 16:36
    
Actually, nm I can see the difference, I did it to a directory first time and a file the next. I was assuming that it would just redirect/modify the VFS as appropriate. Anywho, thanks for the new toy. –  Joel Davis Jun 28 '13 at 16:48

Soft links.

Create two config files, and point to one of them with a soft link most of the time, but change the soft link to point to the other one when the special app is running.

(I know this is a horrible hack, but it's slightly more reliable than changing file contents).

Or, manipulate $HOME.

In the script which starts the annoying process, set $HOME to be something under the regular $HOME directory, and your app should then use the config file located there (tested, and works for basic shell commands, ~ expands to $HOME).

Depending on what else the process does, changing $HOME may have unintended consequences (i.e. output files might end up in the wrong place).

share|improve this answer
    
Good suggestions, thank you. –  Alexander Jun 28 '13 at 11:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.