取决于用户的文件内容
由于一些不幸的原因，我必须将专有的二进制库从每工作站一个用户设置转换为每工作站多用户设置。
当前设置。用户使用链接到库的程序。该库读取系统范围的配置文件（使用硬编码路径，即 /usr/local/thelib/main.conf ），该文件本身包含多个工作目录的路径。 wdir 本身包含一堆用户数据文件。
期望的结果。能够在同一工作站上管理多个用户。当然，用户不能通过库读取或更改任何其他用户的数据，如果我设法为每个用户提供库不同的工作目录，则应由 unix 权限来处理。
该库可能会同时被多个用户使用，因此在运行时在 /usr/local 中导入配置文件不是一个选项。
我正在考虑使用 FUSE 来为文件 /usr/local/thelib/main.conf 提供不同的内容，具体取决于环境变量或当前的 unix 用户。然后，环境变量将用作生成配置文件的代码内的开关。
我可以轻松使用 Python、Perl 或 C。
工作站运行的是最新的 GNU/Linux Debian 或 Ubuntu 发行版，具有最新的内核。
所以。您怎么看：
- 您会使用 FUSE 吗？
- 你会产生另一种包装器 - 根据 janneb 下面建议使用 chroot(2) 吗？
- 使用 Linux 允许的其他东西？
我有点知道我能够生产出一些实用的东西，但我会得到社区的建议，因为我现在不想重新发明轮子。
谢谢。 弗洛里安
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以使用 LD_PRELOAD 加载一个小存根来拦截 open() 调用，并打开 ~/.main.conf （假设这是一个共享对象）。然后在应用程序启动例程中，检查 LD_PRELOAD 是否设置为正确的值，如果没有，请使用正确的环境重新启动应用程序。
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.
一种简单的方法是应用程序在调用库 init 函数之前调用 chroot()。例如，如果您 chroot 到 $HOME/theapp，那么每个用户都可以在 $HOME/theapp/usr/local/thelib/main.conf 中拥有一个私有的配置文件，以及 $HOME/theapp 下某处的私有工作目录。
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.