Subject | Re: [Firebird-Architect] External engines - security |
---|---|
Author | Alex Peshkov |
Post date | 2007-10-22T14:39:44Z |
On Monday 22 October 2007 18:17, Adriano dos Santos Fernandes wrote:
overcomplicate it without need. In suggested by you later samples for
postgres (http://yaofeng.cdut.cn/postgre/7.3/sql-createlanguage.html) and
informix
(http://publib.boulder.ibm.com/infocenter/idshelp/v111/index.jsp?topic=/com.ibm.ddi.doc/ddi108.htm)
it's clear the following ways to create external routines using unsafe
language:
1. Only SYSDBA.
2. SYSDBA + explicitly granted USERS.
3. Everyone (only with Informix, it's possible to disable security checks in
it).
I do not want even start to discuss how secure is the choice number 3:)
When only SYSDBA can create unsafe routines - explain me, please, in what way
is it better then UDF? An ability to grant this right to some user looks like
useful thing, but can you provide a sample when it can be used? An ISP? Some
server inside corporation? Or may be home computer:)
BTW, none of mentioned SQL servers has something similar to UDFs, which may be
stored in special predefined place and later used by any people with
appropriate rights in there databases. Therefore - why store unsafe external
modules in database? How do we limit our server security, not doing it? What
backward compatibility do we avoid, adding unsafe external modules to
database (remember, we must support UDFs)?
> Roman Rokytskyy escreveu:Adriano, I do not understand your arguments here. It was suggested onyl not to
> >> 1. Deal with it exactly like we do with UDFs (which certainly can send
> >> spam and provide other undesired activity if written that way). But due
> >> to limited access to them this it is not a security problem now.
> >
> > I'd go this way. If somebody is needing a flexible language for stored
> > procedures, he would have to choose between safe and slow Java (slow not
> > because it's Java, but because security checks take some time and
> > "context" switching between server and Java code takes some time) and
> > between faster but unsafe Delphi or C++ procedures.
>
> Roman, limiting ability of server security now means we never be able to
> do non-limited things or we should deal with backward compatibility in
> the future.
overcomplicate it without need. In suggested by you later samples for
postgres (http://yaofeng.cdut.cn/postgre/7.3/sql-createlanguage.html) and
informix
(http://publib.boulder.ibm.com/infocenter/idshelp/v111/index.jsp?topic=/com.ibm.ddi.doc/ddi108.htm)
it's clear the following ways to create external routines using unsafe
language:
1. Only SYSDBA.
2. SYSDBA + explicitly granted USERS.
3. Everyone (only with Informix, it's possible to disable security checks in
it).
I do not want even start to discuss how secure is the choice number 3:)
When only SYSDBA can create unsafe routines - explain me, please, in what way
is it better then UDF? An ability to grant this right to some user looks like
useful thing, but can you provide a sample when it can be used? An ISP? Some
server inside corporation? Or may be home computer:)
BTW, none of mentioned SQL servers has something similar to UDFs, which may be
stored in special predefined place and later used by any people with
appropriate rights in there databases. Therefore - why store unsafe external
modules in database? How do we limit our server security, not doing it? What
backward compatibility do we avoid, adding unsafe external modules to
database (remember, we must support UDFs)?