Menu
▾
▴
exist-development
|
From: James F. <jam...@gm...> - 2010-03-24 19:03:35
|
On Wed, Mar 24, 2010 at 7:53 PM, Dmitriy Shabanov <sha...@gm...> wrote:
> Hey,
>
> On Wed, 2010-03-24 at 19:46 +0100, Dannes Wessels wrote:
>> On Wed, Mar 24, 2010 at 7:23 PM, Dmitriy Shabanov <sha...@gm...> wrote:
>> > Do we speak about LibFunction? I don't see any security issue there, or
>> > I'm missing something?
>>
>> > Any scenario?
>>
>> The issue is fundamentally. A jar library is specified by a query,
>> that can live anywhere, even oustide the db. Basically all jar files
>> can be specified,
>> including those who you might not want to expose, e.g. private
>> libraries.
>
> ok, for now it hard-coded to
>
> private final static String LIB_WEBINF = "WEB-INF/lib/";
> private final static String[] LIB = {"./lib/core",
> "./lib/optional", "./lib/extensions", "./lib/user", "."};
>
> so, simples solution hardcode it jars mask like log4j-%latest%.jar too
> (src/org/exist/start/start.config can be used/reused)
>
> Will it solve this problem?
I would also like to have unit test(s) that asserts that it is not a
problem ... though admittedly there are other code 'hotspots'
(including code I am writing) where we need to test with respect to
security, this is probably as good a place to start as anywhere else.
Dont forget, its easy to add xquery level unit tests now as well aka
eXist/test/src/xquery
J
|
|
From: Dmitriy S. <sha...@gm...> - 2010-03-24 19:07:43
Attachments:
smime.p7s
|
On Wed, 2010-03-24 at 19:56 +0100, Dannes Wessels wrote:
> Hi,
>
> On Wed, Mar 24, 2010 at 7:53 PM, Dmitriy Shabanov <sha...@gm...> wrote:
> > ok, for now it hard-coded to
> >
> > private final static String LIB_WEBINF = "WEB-INF/lib/";
> > private final static String[] LIB = {"./lib/core",
> > "./lib/optional", "./lib/extensions", "./lib/user", "."};
> >
> > so, simples solution hardcode it jars mask like log4j-%latest%.jar too
> > (src/org/exist/start/start.config can be used/reused)
> >
> > Will it solve this problem?
>
> No. I put my personal jars in lib/user, these should NEVER be exposed.
> furthermore the classpath is not complete.
How is it possible if it in not in masks list?
My proposal is to use
./lib/core/log4j-%latest%.jar instead ./lib/core (or ./lib/user/fop.jar
instead ./lib/user)
hardcode to jars mask, not folders.
--
Cheers,
Dmitriy Shabanov
|
|
From: Dannes W. <da...@ex...> - 2010-03-24 19:08:35
|
All, I have been discussing this feature for a long time with Evgeny. For a number of reasons I feel really uncomfortable with the new code. On one side the provided functionality, on the other hand, the way the jars ended up into trunk. To start with the latter: it was added to trunk without agreement of the exist-db core team. I had discussions per mail and chat with Evgeny, but these were not successful. I said no but the code ended up in trunk anyway. I feel quite bad on this. About the functionality, my concerns were, and still are: - security (see recent discussions, there is no limit what to download, even private jars); no dbadmin control - double functionality: we have a Webstart interface which provides access to ALL jar files you require to connect with exist-db. Oxygen does not use this interface, but they know of it, since I talked about that. - lack of use case. for weeks I didn't see the added value. A understandable usecase had been missing since the beginning. - lack of testcases other concerns - then original webstart interface was intentionally killed (but denied); fixed in the end after hard discussions - the code was not documented, no comments, no javadoc (being improved) - the name is strange. I still do not agree on "Lib"nothing name. - maintainability. I do not want to check all interfaces and clients if *I* decide to upgrade a jar file, or if we need a new 3rd party jar file. it is hard enough already. We need to consider this seriously Sure things got improved last week, but I still am not convinced about it. I probably *could* live with serving out jar files that are stored in the database. This solves all security issues as well. And the maintenance issue. SO after all, I am still against this addition D. -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
|
From: Dannes W. <da...@ex...> - 2010-03-24 19:12:58
|
Hi, On Wed, Mar 24, 2010 at 8:05 PM, Dmitriy Shabanov <sha...@gm...> wrote: > > My proposal is to use > ./lib/core/log4j-%latest%.jar instead ./lib/core (or ./lib/user/fop.jar > instead ./lib/user) > > hardcode to jars mask, not folders. With this, the functionality will loose the flexibility gev intended to have. See my last mail, think of the maintaince issues we (read: I) will have if we decide to add new jar files. To be more clear: the functionality you describe we basically already have in trunk since years: the webstart interfaces. This interface is well tested, reliable, stable, secure and maintained. Lot's of effort is put in this code, from the beginning of the addition I see the addition as a doubloure we already had. regards Dannes -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
|
From: Dmitriy S. <sha...@gm...> - 2010-03-24 19:13:33
Attachments:
smime.p7s
|
On Wed, 2010-03-24 at 20:03 +0100, James Fuller wrote: > Dont forget, its easy to add xquery level unit tests now as well aka > eXist/test/src/xquery I do not believe to unit tests as you do :-) (especially in security area) -- Cheers, Dmitriy Shabanov |
|
From: James F. <jam...@gm...> - 2010-03-24 19:30:24
|
On Wed, Mar 24, 2010 at 8:11 PM, Dmitriy Shabanov <sha...@gm...> wrote: > On Wed, 2010-03-24 at 20:03 +0100, James Fuller wrote: >> Dont forget, its easy to add xquery level unit tests now as well aka >> eXist/test/src/xquery > > I do not believe to unit tests as you do :-) > (especially in security area) testing (of all types) is one of the few techniques one can employ to achieve good security characteristics in software ... but if you have any other new techniques on the matter, I would love to hear ... I know the answer isn't 'write perfect code' because I have been trying that for 25 years with little success. I don't believe in unit tests as some magic bullet, but at a minimum they do a good job at explaining assumptions a few months/years from now (e.g. those hard coded paths). otherwise, back to the thread ... Dannes needs to be satisfied that all is well with this stuff and as I understand it he isn't because he raised a list of concerns which have yet to be addressed. J |
|
From: Dmitriy S. <sha...@gm...> - 2010-03-24 19:21:41
Attachments:
smime.p7s
|
On Wed, 2010-03-24 at 20:12 +0100, Dannes Wessels wrote: > Hi, > > On Wed, Mar 24, 2010 at 8:05 PM, Dmitriy Shabanov <sha...@gm...> wrote: > > > > My proposal is to use > > ./lib/core/log4j-%latest%.jar instead ./lib/core (or ./lib/user/fop.jar > > instead ./lib/user) > > > > hardcode to jars mask, not folders. > > With this, the functionality will loose the flexibility gev intended > to have. See my last mail, think of the maintaince issues we (read: I) > will have if we decide to add new jar files. > > To be more clear: the functionality you describe we basically already > have in trunk since years: the webstart interfaces. This interface is > well tested, reliable, stable, secure and maintained. Lot's of effort > is put in this code, from the beginning of the addition I see the > addition as a doubloure we already had. The differences that I see is xquery way to access information. eXist information page (xml file) can have the list of jars that are used. If old webstart have all this, can we rewrite xquery functions to use it as backend? -- Cheers, Dmitriy Shabanov PS I do understand all problems, but it should not block ideas :-) |
|
From: Wolfgang M. <wol...@ex...> - 2010-03-24 19:34:44
|
Dannes, you probably invested more time than anyone else into the maintenance of eXist and the quality of our builds. Your opinion thus weighs heavily. > I said no but the code ended up > in trunk anyway. I feel quite bad on this. I do like the gate features Evgeny added and I value his bug fixes and improvements to the trigger code. However, it should be obvious that access to SVN trunk has to be controlled. A "no" from Dannes, if it has been definite, cannot be simply ignored. It can be discussed, sure, and I know he's willing to listen to good arguments. But just committing is not the way to go. So please Evgeny, make a suggestion on how to resolve this issue. Wolfgang |
|
From: Dannes W. <da...@ex...> - 2010-03-24 20:24:50
|
HI, On 24 Mar 2010, at 20:34 , Wolfgang Meier wrote: > I do like the gate features Evgeny added and I value his bug fixes and improvements to the trigger code. Don't get me wrong on this :-) I highly appreciate *any* help and contribution to the eXist-db codebase, no exclusions here! Kind regards Dannes -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
|
From: Evgeny G. <gaz...@gm...> - 2010-03-25 10:13:54
|
Why? Just in JnlpServlet you can get some exist's jar too. all core/optional jars from third part. Idea is give access to guest, otherwise possible to use file module ---------- Evgeny |
|
From: Evgeny G. <gaz...@gm...> - 2010-03-25 10:31:52
|
Simple add path EXIST_HOME/lib/private and put here the your private jars if you have one. ---------- Evgeny |
|
From: Evgeny G. <gaz...@gm...> - 2010-03-25 10:39:50
|
> The differences that I see is xquery way to access information. eXist > information page (xml file) can have the list of jars that are used. > > If old webstart have all this, can we rewrite xquery functions to use it > as backend? > Old JNLP stuf have one hardcoded jnlp and can give access to any core exist's jar. Think that we must move some eXist's functionality like webdav, atom, xmlrpc from servlet layer to xquery webapp. It will be more flexible. And developers could change functionality of this webapp in they's application. So possible add virtual collections for webdav. We need only some basic servlets like REST or XQueryServlet. ---------- Evgeny |
|
From: Dannes W. <da...@ex...> - 2010-03-25 11:58:58
|
On Thu, Mar 25, 2010 at 11:31 AM, Evgeny Gazdovsky <gaz...@gm...> wrote: > Simple add path EXIST_HOME/lib/private and put here the your private jars if you have one. Sure you are right, but that is an implicit result of the changes. Until now my jars were not exposed. On Thu, Mar 25, 2010 at 11:39 AM, Evgeny Gazdovsky <gaz...@gm...> wrote: > Old JNLP stuf have one hardcoded jnlp sorry I refuse to say OLD jnlp code. IMO is the current and primary interface, still. :-) > and can give access to any core exist's jar. But they do not right now...... hardcoded. If we want to expose exist-db internal stuff (e.g. jars) it must be discussed, because of the implicationsm, which are sometimes not directly visible. > We need only some basic servlets like REST or XQueryServlet. Maybe you are right. Maybe not. We decided to design it this way some time ago, probably for good reasons. Any changes must be discussed and agreed on. Realize that the way some parts are coded (direct in servlets) is the most efficient way of IO to the outside world. As I think more of it, probably we should not expose exist-db internal jars. E.g. (1) with all kind of signing issues which will appear (just as you saw yesterday with fluent.jar). Maybe we should store these jars in the database and have these exposed. With this, it is more easy to install and upgrade your java based application (with the coming generic packaging mechanisms) (2) I fear of the maintenance penalties we'll get. I do not wanna test all your apps if i decide to upgrade jars files (or add them to the core) D. -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
|
From: Evgeny G. <gaz...@gm...> - 2010-03-25 12:26:01
|
Storing jars in db is not good way, what about signing jars on the fly and cache then? ------------ Evgeny |
|
From: Dannes W. <da...@ex...> - 2010-03-25 12:51:40
|
Hi, On Thu, Mar 25, 2010 at 1:25 PM, Evgeny Gazdovsky <gaz...@gm...> wrote: > Storing jars in db is not good way, what about signing jars > on the fly and cache then? That is too difficult to get this stable, too error prone. I thought of it..... Anyway we must support pack200 compressed jars as well. For this we need to unsign/normalize/sign/pack200/gzip eachof the jars. Trus me..... that is too difficult on the fly. D. -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
|
From: Evgeny G. <gaz...@gm...> - 2010-03-25 13:15:34
|
> That is too difficult to get this stable, too error prone. I thought of it..... > Anyway we must support pack200 compressed jars as well. For this we > need to unsign/normalize/sign/pack200/gzip eachof the jars. Trus > me..... that is too difficult on the fly. > Ok, put signed jars into different folder(s) (but not in DB)? And share this folder(s) via lib function. So we can have unsigned, signed and packed as pack200 jars -------- Evgeny |
|
From: Adam R. <ad...@ex...> - 2010-03-25 16:27:40
|
> shouldn't those functions be limited to a dba user? Allowing guest to > download any jar file from certain eXist directories seems to be a > security issue. Yes I would agree to that as well. It should only be DBA, for example what about my potentially proprietary extensions and libraries to eXist that are top secret that I keep in lib/endorsed and lib/user, I certainly dont want anyone gaining access to those files! As such if it does require DBA style security, then this module seems somewhat redundant as you could just use the file module! > Wolfgang > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
|
From: Adam R. <ad...@ex...> - 2010-03-25 16:36:35
|
2010/3/24 Wolfgang Meier <wol...@ex...>: >> Which, if I undertand it correctly, also means one of its main >> incentives is void. Making this more like a remove decision. > > Well, as I understand it, Evgeny primarily needs the lib module for > his gate extension. Maybe I missed something (most likely), but I am not clear on what the 'gate' module is, what functionality it offers and who it is useful for (apart from Gev obviously)? Also, this lib module that seems to be in contention, if it is only used by the 'gate' module, why is it separate? Why not keep it as part of the 'gate' module? > Evgeny, could you find a way to secure the lib module while keeping > the gate functionality (even though the latter is not directly related > to eXist, I see the benefits it will have as an example for users)? > > Wolfgang > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
|
From: Wolfgang M. <wol...@ex...> - 2010-03-25 16:50:33
|
@Adam: > Maybe I missed something (most likely), but I am not clear on what the > 'gate' module is, what functionality it offers and who it is useful > for (apart from Gev obviously)? I did not understood it either until Evgeny demonstrated what it does. @Evgeny: I would suggest to accept Jim's offer and do a live presentation. It would help to bring all those discussions to an end and find a solution. You don't need to talk for long. > Suggest one more: add folder(s) for signed jars. > You sign then you share these jars, aren't you? I guess it could be an option if we really need this kind of feature. The jar signing can be pretty complicated though and I broke it a few times myself. It is pretty annoying. Anyway, Dannes knows a lot more about it, so I'm waiting for his opinion. Wolfgang |
|
From: Evgeny G. <gaz...@gm...> - 2010-03-25 16:39:58
|
> Yes I would agree to that as well. It should only be DBA, for example > what about my potentially proprietary extensions and libraries to > eXist that are top secret that I keep in lib/endorsed and lib/user, I > certainly dont want anyone gaining access to those files! > > As such if it does require DBA style security, then this module seems > somewhat redundant as you could just use the file module! > lib functions haven't sense with DBA access only, possible use file module instead. Suggest one more: add folder(s) for signed jars. You sign then you share these jars, aren't you? PS. And all tests (fluent) will be work as well too. ----------- Evgeny |
|
From: Dannes W. <da...@ex...> - 2010-03-25 16:51:58
|
Hi, On Thu, Mar 25, 2010 at 5:39 PM, Evgeny Gazdovsky <gaz...@gm...> wrote: > Suggest one more: add folder(s) for signed jars. > You sign then you share these jars, aren't you? This really sounds like a bad idea. Please don;t.......... really in that case jars in database is a better idea. This way exist jars become one big unmaintainable mess. > PS. And all tests (fluent) will be work as well too. Good. that is the regression part. Please some progression tests as well.... D. -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
|
From: Evgeny G. <gaz...@gm...> - 2010-03-25 17:08:07
|
> This really sounds like a bad idea. Please don;t.......... really in > that case jars in database is a better idea. This way exist jars > become one big unmaintainable mess. > Why? we are sign jars by ant script, during building exist. So putting then into one or some "shared" folder(s) is more maintainable, then put them into db. In last case after rebuilding exist or after replacing old jars by new, you must update them in the db too. Example: $EXIST_HOME/lib/* - for unsigned jars $EXIST_HOME/lib-signed/* - for signed so "lib" or "WEB-INF/lib" are used by eXist in different modes. "lib-signed" for share jars via webstart/applets or any other purpose. ------------ Evgeny |
|
From: Evgeny G. <gaz...@gm...> - 2010-03-25 19:30:29
|
I have one more idea about securing jars. We can add in conf.xml the masks of shared jars (or another files) instead hardcode them. |
|
From: Evgeny G. <gaz...@gm...> - 2010-03-25 19:32:50
|
2010/3/25 Evgeny Gazdovsky <gaz...@gm...>: > I have one more idea about securing jars. > > We can add in conf.xml the masks of shared jars (or another files) > instead hardcode them. > Or create one more config and use it to sign and share jars. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X