Re: Avoiding explicit addDataType calls for PostGIS
От | Markus Schaber |
---|---|
Тема | Re: Avoiding explicit addDataType calls for PostGIS |
Дата | |
Msg-id | 20041007165120.0e8d85f9@kingfisher.intern.logi-track.com обсуждение исходный текст |
Ответ на | Re: Avoiding explicit addDataType calls for PostGIS (Oliver Jowett <oliver@opencloud.com>) |
Список | pgsql-jdbc |
[Sorry for the duplicate message, Oliver, my fist mail was unintentionally sent privately to you] Hi, Oliver, On Thu, 07 Oct 2004 23:31:25 +1300 Oliver Jowett <oliver@opencloud.com> wrote: > > Is the opposite problem possible? I think of the driver class loader be > > able to reach the driver extension, but not the user code class loader. > > That seems unlikely; it'd only happen if you had user code that did not > contain any references to the extension classes. If there are no > references to the extensions, how does the user code use the returned > objects? Reflection, or a common superclass shared by both classloaders, > seem like the only options. It is also possible that the classes were known at compile time, and are used read-only at run-time. That means that the user does not create instances itsself, but only gets them from the db. But I assume this are academic examples. > It's also debatable whether the driver should even allow user code to > cause loading and instantiation of classes that the user code would not > otherwise be able to access.. That's a good question. So, from the security point, we should scan the ressources for possible classes (not eliminating collisions), and then filter all classes the user gives by name (via addDataType, URL or whatever) wether they are allowed (they exist in the ressources file). Markus -- markus schaber | dipl. informatiker logi-track ag | rennweg 14-16 | ch 8001 zürich phone +41-43-888 62 52 | fax +41-43-888 62 53 mailto:schabios@logi-track.com | www.logi-track.com
В списке pgsql-jdbc по дате отправления: