User-dependent file content

Question

Hi.

For some unfortunate reasons, I have to convert a proprietary and binary library from a one-user per workstation to a multi-user per workstation setup.

Current setup. A user uses a program linked against a library. This library reads a system wide configuration file (using an hard-coded path, ie /usr/local/thelib/main.conf ) which itself contains several paths to several working directories. The wdir are themselves containing a bunch of user data files.

Desired outcome. Being able to manage several users on the same workstation. Of course, a user shall not be able to read nor alter any other user's data through the library, which should be taken care of by unix rights if I manage to feed the library a different working directory for each user.

The library might be used by several users at the same time so ln-ing the configuration file in /usr/local at runtime is not an option.

I was thinking of using FUSE in order to provide a different content for the file /usr/local/thelib/main.conf, depending on an environnement variable or the current unix user. The environnement var would then be used as a switch inside the code producing the configuration file.

I'm confortable using Python, Perl or C.

The workstation is running an up-to-date GNU/Linux Debian or Ubuntu distribution with a pretty recent kernel.

So. What do you think :

• would you use FUSE ?
• would you produce another kind of wrapper - using chroot(2) was suggested below per janneb - ?
• use something else allowed by Linux ?

I kinda know that I would be able to produce something functional but I'll get the community advice since I don't want to reinvent the wheel right now.

Thanks. Florian

Answer 1

A simple way would be for the app to call chroot() before calling the library init function(s). E.g. if you chroot into $HOME/theapp then each user can have a private own config file in $HOME/theapp/usr/local/thelib/main.conf as well as private working dirs somewhere under $HOME/theapp.

Answer 2

you could use LD_PRELOAD to load a small stub that intercepts open() calls, and opens ~/.main.conf (assuming this is a shared object). Then in your application startup routine, check that LD_PRELOAD is set to the correct value, and if not, restart the app with the correct environment.