XML_Parse /lib/einit/bootstrap/bootstrap-configuration-xml-expat.so
yeah this is on purpose. the reason was that einit needs expat before /usr is guaranteed to be mounted. normally we'd have just linked in expat statically, but /usr/lib/libexpat.a cannot be linked statically into a .so file since it's compiled without -fPIC, which would be needed. and linking that .so against /usr/lib/libexpat.so wouldn't have worked either, since /usr is not necessarily available by the time einit is executed.
So we can close this bug as INVALID?
This is not invalid, it's a very valid bug. While the reasoning is partially sound, it means we have to find a solution to the problem, rather than allowing internal copies of libraries.
well, einit has been discontinued and its successor (kyuba) isn't going to use XML but instead plain S-Expressions, so it's not exactly going to be a problem in the future. one solution would have been to put libexpat.so* in /lib instead of /usr/lib, but I'm pretty sure that most programmes using expat aren't low-level enough to be run without /usr, so libexpat shouldn't clutter up the root filesystem.
I forgot to point this out, but, einit's libexpat isn't actually a copy from the host system's libexpat, but instead its compiled from expat source code bundled with einit's source code tree.
(In reply to comment #3) > While the reasoning is partially sound, it means we have to find a solution to > the problem, rather than allowing internal copies of libraries. What 'problem' is it causing?.. I don't see any issues arising with such a package building it's own copy of a lib if it isn't available at the pre-mount boot stage. Can you explain what issue you have with this? So everybody can be on the same page.
(In reply to comment #6) > (In reply to comment #3) > > While the reasoning is partially sound, it means we have to find a solution to > > the problem, rather than allowing internal copies of libraries. > > What 'problem' is it causing?.. I don't see any issues arising with such a > package building it's own copy of a lib if it isn't available at the pre-mount > boot stage. > > Can you explain what issue you have with this? So everybody can be on the same > page. One issue is that a security problem is hard to fix with bundled expat everywhere: http://blog.flameeyes.eu/2009/08/21/i-told-you-so-the-expat-debacle einit will be removed from the tree as it is discontinued anyway.
Magnus, I'm trying to assess a possible security impact of this bug. Having a short look over the tool, it seems to open only XML files that are under control of the admin and stored in /etc. Is that correct, or are there situations where user-provided XML files are being read?
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #3) > > > While the reasoning is partially sound, it means we have to find a solution to > > > the problem, rather than allowing internal copies of libraries. > > > > What 'problem' is it causing?.. I don't see any issues arising with such a > > package building it's own copy of a lib if it isn't available at the pre-mount > > boot stage. > > > > Can you explain what issue you have with this? So everybody can be on the same > > page. > > One issue is that a security problem is hard to fix with bundled expat > everywhere: http://blog.flameeyes.eu/2009/08/21/i-told-you-so-the-expat-debacle > > einit will be removed from the tree as it is discontinued anyway. > that one is actually pretty new, back when this bug was opened there really wasn't much of a reason for this report, with the possible exception of inflating the root fs by roughly 100kbytes. if it were still supported, i'd have just packed up the latest version of expat with einit. it's not like i *wanted* to do this anyway, but unfortunately it was the only way, unless someone would have a better idea for the future? i mean really, i'd be open to suggestions. funnily enough, i'm pretty sure that if i had just written my own xml parser, this bug would never have been opened. i suppose i'd have gotten semi-serious flames all over the place for re-inventing the wheel, but no funky bug reports. (In reply to comment #8) > Magnus, I'm trying to assess a possible security impact of this bug. Having a > short look over the tool, it seems to open only XML files that are under > control of the admin and stored in /etc. Is that correct, or are there > situations where user-provided XML files are being read? > Robert, don't worry too much about that one, as you said there's no user-supplied .xml files being parsed anywhere, only files in /etc/einit and /lib/einit to which no user should have access anyway. so, unless an admin deliberately wants to make einit crash by exploiting that expat bug, or the admin sets inclusion paths in the config files to some paths users can write to, nothing's gonna happen. and an admin has far easier possibilities to get einit to crash anyway :D.
The impact of such bundled libraries has always been the same, now is the time that the warnings have come true for einit. I remember that we fixed bundled versions of zlib years after the discovery of a security vulnerability (erlang as an example). There has been no answer to your initial question for so long, because it fell off my radar. It is like not using the safety belt because there is no problem currently...and then having a crash.
(In reply to comment #10) > The impact of such bundled libraries has always been the same, now is the time > that the warnings have come true for einit. I remember that we fixed bundled > versions of zlib years after the discovery of a security vulnerability (erlang > as an example). There has been no answer to your initial question for so long, > because it fell off my radar. > It is like not using the safety belt because there is no problem > currently...and then having a crash. > heh, hey dont get me wrong, i do see the issue in principle, its just that there really wasn't any other way of avoiding the issue, short of writing my own xml parser, which i wasnt inclined to do back then and im not inclined to do it anytime soon either. so, the analogy would be more like not using the safety belt because it's broken and the mechanic says he can't procure a replacement... and then having a crash.
Gone from the tree.
