View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003705 | unreal | ircd | public | 2008-06-18 20:59 | 2015-08-08 09:33 |
| Reporter | Stealth | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Platform | * | OS | * | OS Version | * |
| Product Version | 3.2.7 | ||||
| Summary | 0003705: Review Gentoo Patches | ||||
| Description | We should check out the Gentoo patches to see if they were real 'security issues' or just the Gentoo people doing stupid stuff with our IRCd. If the patches really do fix stuff, they should be applied. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Please take a look at this bug. I would be interested to know if the module copy before load is needed. http://bugs.gentoo.org/show_bug.cgi?id=223835 Trusted Path Execution in the grsecurity patches breaks unrealircd by preventing any modules from loading. The /tmp/*.so module is owned by a non-root and non-tpe-trusted user and gets denied execution. |
|
|
It's most assuredly not required if the install process operates 'properly', which it currently doesn't By that, I mean that using 'cp' and equivilants to move shared objects around breaks things, which this copy hack is aimed at bypassing - if instead of this, shared objects were installed into a lib/ directory (or whatever) inside Unreal's folder through `install' (1) instead of cp, the problems of overwriting shared objects while running would go away. (We had this problem with InspIRCd a few years ago - I'm surprised nobody's found the solution yet..) Though, I'm not sure what kind of a timeline you'd see on a fix, cdf123. Things have been a bit slow for a while here. |
|
|
If your question is why we are copying to a tmp directory (tmp/ inside of the Unreal directory of course, not /tmp.. that would be a horrible idea) then the answer is: because otherwise a new version of a module would not load. This is because Unreal does "SAFE" module reloading, meaning: when we rehash (reload a module) we don't close the old module handle (dlclose) and then open the new one (dlopen), no.. we KEEP the old one open and THEN open a new one and do some checks and if they pass the old one is closed. This makes sure that not something odd can happen between closing the old one and opening the new one(eg: out of fds, or.. well several possibilities). In contrast to MANY other software, which does not do this... I hope inspircd is not one of them, anope is I think.. That's the only reason for hardlink and/or copy, it's to fool the dl loader which will otherwise NOT load the new module because it knows the old one is still in memory and THINKS it's the same (reference count...), even though it's not... Oh and yes, I suppose it also helps against overwrites, such as someone compiling or copying things over, but that's just an extra bonus. So, if you removed the copy-or-hardlink-before-load, then you just broke the upgrade-on-the-fly capability. |
|
|
Oh, I wasn't aware you tried to reload everything on a /rehash, we don't do that as it would be way, way too slow with the number of modules we have (and, as you've observed, because we don't have a /tmp copy). Instead, on rehash, two lists are generated; modules which have been unloaded - as well as ones that have been loaded. Those two are processed, anything not on those lists isn't touched. To 'upgrade on the fly', /reloadmodule m_blah.so or /unloadmodule and /reloadmodule are required. |
|
|
Is this still an issue? Or did we determine this is entirely to do with Gentoo's ports? |
|
|
implementing this breaks things rather than solving anything :P. |
|
|
May this be made compile-time configurable to support hardened systems? If someone is running Gentoo hardened and does a /rehash, there is no need to reload modules because none of them will have changed. Also, perhaps there is a more correct way to force libdl to reload a library. |
|
|
There is -- load the module with RTLD_LOCAL rather than RTLD_GLOBAL. The symbol table will still be shared. |
|
|
Closing as, as said, 'fixing' this would cause more problems. (what neno was saying is what we are doing already for 10+ years, doesn't help) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-06-18 20:59 | Stealth | New Issue | |
| 2008-06-18 20:59 | Stealth | QA | => Not touched yet by developer |
| 2008-06-18 20:59 | Stealth | U4: Need for upstream patch | => No need for upstream InspIRCd patch |
| 2008-06-18 20:59 | Stealth | U4: Upstream notification of bug | => Not decided |
| 2008-06-18 20:59 | Stealth | U4: Contributor working on this | => None |
| 2008-06-18 21:03 | Stealth | Status | new => acknowledged |
| 2008-06-27 16:05 | cdf123 | Note Added: 0015314 | |
| 2008-07-02 14:57 | w00t | Note Added: 0015317 | |
| 2008-08-04 08:26 | syzop | Note Added: 0015336 | |
| 2008-08-04 08:59 | w00t | Note Added: 0015337 | |
| 2009-07-24 01:21 | Stealth | Note Added: 0015898 | |
| 2009-07-24 01:21 | Stealth | Status | acknowledged => feedback |
| 2009-08-17 11:49 | syzop | Note Added: 0015925 | |
| 2009-08-17 11:49 | syzop | Status | feedback => closed |
| 2009-08-17 11:50 | syzop | Resolution | open => no change required |
| 2010-08-23 19:02 | ohnobinki | Note Added: 0016307 | |
| 2010-08-23 19:02 | ohnobinki | Status | closed => new |
| 2012-03-07 03:54 |
|
Note Added: 0016949 | |
| 2015-08-08 09:33 | syzop | Note Added: 0018586 | |
| 2015-08-08 09:33 | syzop | Status | new => closed |
| 2015-08-08 09:33 | syzop | Assigned To | => syzop |
