View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002300 | unreal | ircd | public | 2005-01-23 17:15 | 2005-02-03 19:53 |
| Reporter | kronos | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.2.2 | ||||
| Fixed in Version | 3.2.3 | ||||
| Summary | 0002300: Modules are copied to temporary directory | ||||
| Description | Modules are copied to a temporary directory and then loaded from there, making it impossible to properly restrict access using RSBAC. (Any daemon should not be able to modify its own executables or libraries.) There should be an option to load modules in-place without copying. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
That would mean modules cannot be reloaded from disk on rehash. I'm not exactly sure if we would want to implement this feature (probably quite a bit of work & only in very few cases useful) [read: I am not going to code it] |
|
|
Can you explain why the modules need to be copied before they can be reloaded? |
|
|
It's both complicated and simple.. it's not that they need to be copied before they can be reloaded.. it's that they need to be copied in the first place.. It all has to do with dlopen/dlclose caching and reference counts and Unreal's safe internal loading mechanism... which means: while we have f.e. mod1 loaded, and rehash, we open mod1 again.. to verify a few things [test/header/..] and then we unload the old mod1 and continue loading the new mod1.. problem is dlopen() uses reference counts so the 2nd dlopen will use the "old/original" module and not read the "new" one from disk. By copying the module over and use random names we evade this problem. ** Actually, hardlinking would work too.. I forgot why we didn't do that, but it might solve your problem... Well, I'm not familiar with the security system you use but for example for systrace it would work, perhaps for grsecurity' RBAC as well but it could well be that they don't have a special link flag. |
|
|
Yes, hard-linking would solve the problem |
|
|
Good, then this will probably be done. |
|
|
Done in .253 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-01-23 17:15 | kronos | New Issue | |
| 2005-01-23 17:23 | syzop | Note Added: 0008903 | |
| 2005-01-23 17:23 | syzop | Note Edited: 0008903 | |
| 2005-01-23 17:35 | kronos | Note Added: 0008904 | |
| 2005-01-23 17:46 | syzop | Note Added: 0008905 | |
| 2005-01-23 17:51 | kronos | Note Added: 0008906 | |
| 2005-01-23 18:04 | syzop | Note Added: 0008907 | |
| 2005-01-24 20:57 | syzop | View Status | public => private |
| 2005-02-03 19:51 | syzop | View Status | private => public |
| 2005-02-03 19:53 | syzop | Status | new => resolved |
| 2005-02-03 19:53 | syzop | Fixed in Version | => 3.2.3 |
| 2005-02-03 19:53 | syzop | Resolution | open => fixed |
| 2005-02-03 19:53 | syzop | Assigned To | => syzop |
| 2005-02-03 19:53 | syzop | Note Added: 0009012 |
