Overly zealous security of schemas...

Overly zealous security of schemas...

Post by Sean Chittend » Mon, 28 Apr 2003 05:49:43



--52aklQ8BZHJhx2Z3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Howdy.  It looks as though the checks that allow for access to schemas
doesn't check the correct permissions of the running user in that if a
function is being run as the security definer, the schema checks still
check the session_user.  Am I missing the work around someplace or is
this a bug?  Here's the example code to demonstrate this problem:

/* BEGIN */
\c template1 pgsql
DROP DATABASE test;
CREATE DATABASE test WITH OWNER dba;

\c test pgsql
BEGIN;
-- In case pl/plpgsql isn't loaded
CREATE FUNCTION plpgsql_call_handler () RETURNS language_handler
    AS '$libdir/plpgsql', 'plpgsql_call_handler'
    LANGUAGE c;

CREATE TRUSTED PROCEDURAL LANGUAGE plpgsql HANDLER plpgsql_call_handler;
COMMIT;

\c test dba
BEGIN;
CREATE SCHEMA s AUTHORIZATION dba;
SET search_path TO s;
CREATE TABLE t (i INT);
CREATE TABLE c (i INT, PRIMARY KEY(i));
ALTER TABLE s.t ADD FOREIGN KEY(i) REFERENCES s.c(i);

SET search_path TO public;
CREATE FUNCTION t_ins(INT)
    RETURNS INT
    EXTERNAL SECURITY DEFINER
    AS '
DECLARE
      v_usr TEXT;
BEGIN
      SELECT current_user INTO v_usr;
      RAISE NOTICE ''current_user: %'', v_usr;
      SELECT session_user INTO v_usr;
      RAISE NOTICE ''session_user: %'', v_usr;

      INSERT INTO s.t (i) VALUES ($1);
      RETURN $1;
END;
' LANGUAGE 'plpgsql';

SET search_path TO public;

REVOKE ALL ON SCHEMA public,s FROM PUBLIC;
GRANT EXECUTE ON FUNCTION t_ins(INT) TO PUBLIC;

-- Unnecessary grant, but example is explicit at least
GRANT USAGE ON SCHEMA s TO dba;

-- Usage has to be granted to the PUBLIC in order for this to work,
-- even though the function is being run as the dba user: this
-- seems broken in that session_user isn't being set correctly when a
-- function is run as the security definer, or that schema checks
-- aren't consulting the current_user and are consulting the
-- session_user.  Anyway, for the sake of correctness, comment out the
-- GRANT command for now, but if you want to see this example work
-- from start to finish, uncomment the following line.
--
-- GRANT USAGE ON SCHEMA s TO PUBLIC;
INSERT INTO s.c VALUES (42);
COMMIT;

\c test dba
-- Works
SELECT t_ins(42);
\c test normal_user
-- Doesn't work unless you run: GRANT USAGE ON SCHEMA s TO PUBLIC;
SELECT t_ins(42);
/* END */

The place where this breaks down is in the foreign key constraints, it
can't select 1 from the s schema and returns a permission denied.

test=3D> SELECT t_ins(42);
NOTICE:  current_user: dba
NOTICE:  session_user: normal_user
ERROR:  s: permission denied

-sc

--=20
Sean Chittenden

--52aklQ8BZHJhx2Z3
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----

iD8DBQE+qvCX3ZnjH7yEs0ERAuYxAJsGLV7duNobdGE/n6l3KcAWlf5+4wCgn4N5
FBPaoRymjBNrNUT9tDjNnV8=
=PZiD
-----END PGP SIGNATURE-----

--52aklQ8BZHJhx2Z3--

 
 
 

Overly zealous security of schemas...

Post by Tom La » Mon, 28 Apr 2003 06:20:39



> Howdy.  It looks as though the checks that allow for access to schemas
> doesn't check the correct permissions of the running user in that if a
> function is being run as the security definer, the schema checks still
> check the session_user.  Am I missing the work around someplace or is
> this a bug?

It looks to me like the bug is not related to the use of a SECURITY
DEFINER function at all, but just to the use of foreign keys.  The
RI triggers know they should setuid to the table owner for execution
of their generated queries --- but they fail to do so for parsing the
queries.  So parse-time security checks (such as USAGE on schemas)
will fail.

I think you can make the same problem happen without a SECURITY DEFINER
function --- what you need is user A inserting into table B, which has
an FK reference to table C, which is in a schema that B's owner has
USAGE rights on but A doesn't.  Would you try it?

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

 
 
 

Overly zealous security of schemas...

Post by Sean Chittend » Mon, 28 Apr 2003 06:36:56


Quote:> > Howdy.  It looks as though the checks that allow for access to
> > schemas doesn't check the correct permissions of the running user
> > in that if a function is being run as the security definer, the
> > schema checks still check the session_user.  Am I missing the work
> > around someplace or is this a bug?

> It looks to me like the bug is not related to the use of a SECURITY
> DEFINER function at all, but just to the use of foreign keys.  The
> RI triggers know they should setuid to the table owner for execution
> of their generated queries --- but they fail to do so for parsing
> the queries.  So parse-time security checks (such as USAGE on
> schemas) will fail.

Ah, I had this backwards: I thought SECURITY DEFINER wasn't setting
something that'd allow the foreign keys to run as the owner of the
function.

Quote:> I think you can make the same problem happen without a SECURITY
> DEFINER function --- what you need is user A inserting into table B,
> which has an FK reference to table C, which is in a schema that B's
> owner has USAGE rights on but A doesn't.  Would you try it?

Yep, you're right.  Here's the test script + logput:

/* Begin */
\c template1 pgsql
DROP DATABASE test;
CREATE DATABASE test WITH OWNER dba;

\c test dba
BEGIN;
CREATE SCHEMA s AUTHORIZATION dba;
CREATE TABLE s.c (i INT, PRIMARY KEY(i));
CREATE TABLE public.t (i INT);
ALTER TABLE public.t ADD FOREIGN KEY(i) REFERENCES s.c(i);

REVOKE ALL ON SCHEMA s FROM PUBLIC;
GRANT INSERT,SELECT ON TABLE t TO PUBLIC;
INSERT INTO s.c VALUES (42);
COMMIT;

\c test normal_user
INSERT INTO t VALUES (42);
/* End */

And the bits from the log file:
2003-04-26 14:29:39 [1044]   LOG:  query: INSERT INTO t VALUES (42);
2003-04-26 14:29:39 [1044]   LOG:  query: SELECT 1 FROM ONLY "s"."c" x WHERE "i" = $1 FOR UPDATE OF x
2003-04-26 14:29:39 [1044]   ERROR:  s: permission denied

-sc

--
Sean Chittenden

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

 
 
 

Overly zealous security of schemas...

Post by Sean Chittend » Mon, 28 Apr 2003 07:17:25


Quote:> > > Howdy.  It looks as though the checks that allow for access to
> > > schemas doesn't check the correct permissions of the running user
> > > in that if a function is being run as the security definer, the
> > > schema checks still check the session_user.  Am I missing the work
> > > around someplace or is this a bug?

> > It looks to me like the bug is not related to the use of a SECURITY
> > DEFINER function at all, but just to the use of foreign keys.  The
> > RI triggers know they should setuid to the table owner for execution
> > of their generated queries --- but they fail to do so for parsing
> > the queries.  So parse-time security checks (such as USAGE on
> > schemas) will fail.

> Ah, I had this backwards: I thought SECURITY DEFINER wasn't setting
> something that'd allow the foreign keys to run as the owner of the
> function.

> > I think you can make the same problem happen without a SECURITY
> > DEFINER function --- what you need is user A inserting into table B,
> > which has an FK reference to table C, which is in a schema that B's
> > owner has USAGE rights on but A doesn't.  Would you try it?

> Yep, you're right.

And actually, it looks like sequences have this same problem as well,
only things are slightly worse there: you have to grant SELECT,UPDATE
to a sequence to the public in order for those to work
automagically. :-/

-sc

--
Sean Chittenden

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly

 
 
 

Overly zealous security of schemas...

Post by Tom La » Mon, 28 Apr 2003 07:25:32


Sean Chittenden <s...@chittenden.org> writes:
> Ah, I had this backwards: I thought SECURITY DEFINER wasn't setting
> something that'd allow the foreign keys to run as the owner of the
> function.

Nah; by the time the RI triggers run, you're out of the function
entirely.  So they have to fend for themselves.

Here's the 7.3 version of the patch (it's a bit ugly because I had to
back-port a couple of changes that are in CVS tip).

                        regards, tom lane

*** src/backend/utils/adt/ri_triggers.c.orig    Thu Mar 27 14:25:52 2003
--- src/backend/utils/adt/ri_triggers.c Sat Apr 26 18:12:16 2003
***************
*** 58,74 ****
  #define RI_KEYS_SOME_NULL                             1
  #define RI_KEYS_NONE_NULL                             2

!
  #define RI_PLAN_CHECK_LOOKUPPK_NOCOLS 1
  #define RI_PLAN_CHECK_LOOKUPPK                        2
! #define RI_PLAN_CASCADE_DEL_DODELETE  1
! #define RI_PLAN_CASCADE_UPD_DOUPDATE  1
! #define RI_PLAN_NOACTION_DEL_CHECKREF 1
! #define RI_PLAN_NOACTION_UPD_CHECKREF 1
! #define RI_PLAN_RESTRICT_DEL_CHECKREF 1
! #define RI_PLAN_RESTRICT_UPD_CHECKREF 1
! #define RI_PLAN_SETNULL_DEL_DOUPDATE  1
! #define RI_PLAN_SETNULL_UPD_DOUPDATE  1

  #define MAX_QUOTED_NAME_LEN  (NAMEDATALEN*2+3)
  #define MAX_QUOTED_REL_NAME_LEN  (MAX_QUOTED_NAME_LEN*2)
--- 58,75 ----
  #define RI_KEYS_SOME_NULL                             1
  #define RI_KEYS_NONE_NULL                             2

! /* queryno values must be distinct for the convenience of ri_PerformCheck */
  #define RI_PLAN_CHECK_LOOKUPPK_NOCOLS 1
  #define RI_PLAN_CHECK_LOOKUPPK                        2
! #define RI_PLAN_CASCADE_DEL_DODELETE  3
! #define RI_PLAN_CASCADE_UPD_DOUPDATE  4
! #define RI_PLAN_NOACTION_DEL_CHECKREF 5
! #define RI_PLAN_NOACTION_UPD_CHECKREF 6
! #define RI_PLAN_RESTRICT_DEL_CHECKREF 7
! #define RI_PLAN_RESTRICT_UPD_CHECKREF 8
! #define RI_PLAN_SETNULL_DEL_DOUPDATE  9
! #define RI_PLAN_SETNULL_UPD_DOUPDATE  10
! #define RI_PLAN_KEYEQUAL_UPD                  11

  #define MAX_QUOTED_NAME_LEN  (NAMEDATALEN*2+3)
  #define MAX_QUOTED_REL_NAME_LEN  (MAX_QUOTED_NAME_LEN*2)
***************
*** 149,154 ****
--- 150,159 ----
  static void ri_InitHashTables(void);
  static void *ri_FetchPreparedPlan(RI_QueryKey *key);
  static void ri_HashPreparedPlan(RI_QueryKey *key, void *plan);
+ static void *ri_PlanCheck(char *querystr, int nargs, Oid *argtypes,
+                                                 RI_QueryKey *qkey, Relation fk_rel, Relation pk_rel,
+                                                 bool cache_plan);
+

  /* ----------
   * RI_FKey_check -
***************
*** 264,269 ****
--- 269,277 ----
                                                         fk_rel, pk_rel,
                                                         tgnargs, tgargs);

+               if (SPI_connect() != SPI_OK_CONNECT)
+                       elog(ERROR, "SPI_connect() failed in RI_FKey_check()");
+
                if ((qplan = ri_FetchPreparedPlan(&qkey)) == NULL)
                {
                        char            querystr[MAX_QUOTED_REL_NAME_LEN + 100];
***************
*** 278,297 ****
                        snprintf(querystr, sizeof(querystr), "SELECT 1 FROM ONLY %s x FOR UPDATE OF x",
                                         pkrelname);

!                       /*
!                        * Prepare, save and remember the new plan.
!                        */
!                       qplan = SPI_prepare(querystr, 0, NULL);
!                       qplan = SPI_saveplan(qplan);
!                       ri_HashPreparedPlan(&qkey, qplan);
                }

                /*
                 * Execute the plan
                 */
-               if (SPI_connect() != SPI_OK_CONNECT)
-                       elog(WARNING, "SPI_connect() failed in RI_FKey_check()");
-
                SetUserId(RelationGetForm(pk_rel)->relowner);

                if (SPI_execp(qplan, check_values, check_nulls, 1) != SPI_OK_SELECT)
--- 286,299 ----
                        snprintf(querystr, sizeof(querystr), "SELECT 1 FROM ONLY %s x FOR UPDATE OF x",
                                         pkrelname);

!                       /* Prepare and save the plan */
!                       qplan = ri_PlanCheck(querystr, 0, NULL,
!                                                                &qkey, fk_rel, pk_rel, true);
                }

                /*
                 * Execute the plan
                 */
                SetUserId(RelationGetForm(pk_rel)->relowner);

                if (SPI_execp(qplan, check_values, check_nulls, 1) != SPI_OK_SELECT)
***************
*** 420,426 ****
                 * The query string built is
                 *      SELECT 1 FROM ONLY <pktable> WHERE pkatt1 = $1 [AND ...]
                 * The type id's for the $ parameters are those of the
!                * corresponding FK attributes. Thus, SPI_prepare could
                 * eventually fail if the parser cannot identify some way
                 * how to compare these two types by '='.
                 * ----------
--- 422,428 ----
                 * The query string built is
                 *      SELECT 1 FROM ONLY <pktable> WHERE pkatt1 = $1 [AND ...]
                 * The type id's for the $ parameters are those of the
!                * corresponding FK attributes. Thus, ri_PlanCheck could
                 * eventually fail if the parser cannot identify some way
                 * how to compare these two types by '='.
                 * ----------
***************
*** 440,451 ****
                }
                strcat(querystr, " FOR UPDATE OF x");

!               /*
!                * Prepare, save and remember the new plan.
!                */
!               qplan = SPI_prepare(querystr, qkey.nkeypairs, queryoids);
!               qplan = SPI_saveplan(qplan);
!               ri_HashPreparedPlan(&qkey, qplan);
        }

        /*
--- 442,450 ----
                }
                strcat(querystr, " FOR UPDATE OF x");

!               /* Prepare and save the plan */
!               qplan = ri_PlanCheck(querystr, qkey.nkeypairs, queryoids,
!                                                        &qkey, fk_rel, pk_rel, true);
        }

        /*
***************
*** 625,631 ****
                 * The query string built is
                 *      SELECT 1 FROM ONLY <pktable> WHERE pkatt1 = $1 [AND ...]
                 * The type id's for the $ parameters are those of the
!                * corresponding FK attributes. Thus, SPI_prepare could
                 * eventually fail if the parser cannot identify some way
                 * how to compare these two types by '='.
                 * ----------
--- 624,630 ----
                 * The query string built is
                 *      SELECT 1 FROM ONLY <pktable> WHERE pkatt1 = $1 [AND ...]
                 * The type id's for the $ parameters are those of the
!                * corresponding FK attributes. Thus, ri_PlanCheck could
                 * eventually fail if the parser cannot identify some way
                 * how to compare these two types by '='.
                 * ----------
***************
*** 645,656 ****
                }
                strcat(querystr, " FOR UPDATE OF x");

!               /*
!                * Prepare, save and remember the new plan.
!                */
!               qplan = SPI_prepare(querystr, qkey.nkeypairs, queryoids);
!               qplan = SPI_saveplan(qplan);
!               ri_HashPreparedPlan(&qkey, qplan);
        }

        /*
--- 644,652 ----
                }
                strcat(querystr, " FOR UPDATE OF x");

!               /* Prepare and save the plan */
!               qplan = ri_PlanCheck(querystr, qkey.nkeypairs, queryoids,
!                                                        &qkey, pk_rel, pk_rel, true);
        }

        /*
***************
*** 834,840 ****
                                 * The query string built is
                                 *      SELECT 1 FROM ONLY <fktable> WHERE fkatt1 = $1 [AND ...]
                                 * The type id's for the $ parameters are those of the
!                                * corresponding PK attributes. Thus, SPI_prepare could
                                 * eventually fail if the parser cannot identify some way
                                 * how to compare these two types by '='.
                                 * ----------
--- 830,836 ----
                                 * The query string built is
                                 *      SELECT 1 FROM ONLY <fktable> WHERE fkatt1 = $1 [AND ...]
                                 * The type id's for the $ parameters are those of the
!                                * corresponding PK attributes. Thus, ri_PlanCheck could
                                 * eventually fail if the parser cannot identify some way
                                 * how to compare these two types by '='.
                                 * ----------
***************
*** 854,865 ****
                                }
                                strcat(querystr, " FOR UPDATE OF x");

!                               /*
!                                * Prepare, save and remember the new plan.
!                                */
!                               qplan = SPI_prepare(querystr, qkey.nkeypairs, queryoids);
!                               qplan = SPI_saveplan(qplan);
!                               ri_HashPreparedPlan(&qkey, qplan);
                        }

                        /*
--- 850,858 ----
                                }
                                strcat(querystr, " FOR UPDATE OF x");

!                               /* Prepare and save the plan */
!                               qplan = ri_PlanCheck(querystr, qkey.nkeypairs, queryoids,
!                                                                        &qkey, fk_rel, pk_rel, true);
                        }

                        /*
***************
*** 1075,1081 ****
                                 * The query string built is
                                 *      SELECT 1 FROM ONLY <fktable> WHERE fkatt1 = $1 [AND ...]
                                 * The type id's for the $ parameters are those of the
!                                * corresponding PK attributes. Thus, SPI_prepare could
                                 * eventually fail if the parser cannot identify some way
                                 * how to compare these two types by '='.
                                 * ----------
--- 1068,1074 ----
                                 * The query string built is
                                 *      SELECT 1 FROM ONLY <fktable> WHERE fkatt1 = $1 [AND ...]
                                 * The type id's for the $ parameters are those of the
!                                * corresponding PK attributes. Thus, ri_PlanCheck could
                                 * eventually fail if the parser cannot identify some way
                                 * how to compare these two types by '='.
                                 * ----------
***************
*** 1095,1106 ****
                                }
                                strcat(querystr, " FOR UPDATE OF x");

!                               /*
!                                * Prepare, save and remember the new plan.
!                                */
!                               qplan = SPI_prepare(querystr, qkey.nkeypairs, queryoids);
!                               qplan = SPI_saveplan(qplan);
!                               ri_HashPreparedPlan(&qkey, qplan);
                        }

                        /*
--- 1088,1096 ----
                                }
                                strcat(querystr, " FOR UPDATE OF x");

!                               /* Prepare and save the plan */
!                               qplan = ri_PlanCheck(querystr, qkey.nkeypairs, queryoids,
!                                                                        &qkey, fk_rel, pk_rel, true);
                        }

                        /*
***************
*** 1288,1294 ****
                                 * The query string built is
                                 *      DELETE FROM ONLY <fktable> WHERE fkatt1 = $1 [AND ...]
                                 * The type id's for the $ parameters are those of the
!                                * corresponding PK attributes. Thus, SPI_prepare could
                                 * eventually fail if the parser cannot identify some way
                                 * how to compare these two types by '='.
                                 * ----------
--- 1278,1284 ----
                                 * The query string built is
                                 *      DELETE FROM ONLY <fktable> WHERE fkatt1 = $1 [AND ...]
                                 * The type id's for the $ parameters are those of the
!                                * corresponding PK attributes. Thus, ri_PlanCheck could
                                 * eventually fail if the parser cannot identify some way
                                 * how to compare these two types by '='.
                                 * ----------
***************
*** 1307,1318 ****
                                                                         qkey.keypair[i][RI_KEYPAIR_PK_IDX]);
                                }

!                               /*
!                                * Prepare, save and remember the new plan.
!                                */
!                               qplan = SPI_prepare(querystr, qkey.nkeypairs, queryoids);
!                               qplan = SPI_saveplan(qplan);
!                               ri_HashPreparedPlan(&qkey, qplan);
                        }

                        /*
--- 1297,1305 ----
                                                                         qkey.keypair[i][RI_KEYPAIR_PK_IDX]);
                                }
...

read more »

 
 
 

Overly zealous security of schemas...

Post by Tom La » Mon, 28 Apr 2003 07:26:12



> And actually, it looks like sequences have this same problem as well,
> only things are slightly worse there: you have to grant SELECT,UPDATE
> to a sequence to the public in order for those to work
> automagically. :-/

That's always been true though.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

 
 
 

Overly zealous security of schemas...

Post by Sean Chittend » Mon, 28 Apr 2003 07:35:01


Quote:> > And actually, it looks like sequences have this same problem as
> > well, only things are slightly worse there: you have to grant
> > SELECT,UPDATE to a sequence to the public in order for those to
> > work automagically. :-/

> That's always been true though.

True, but while we're on the topic, I figured I'd give things a shot
in the, could this be fixed dept.  Inserting into a view with a rule,
the resulting query is run as the rule executor, not as the rule
definer.  If that were somehow possible, then it'd remove the need to
have a rule rewrite the (insert|update|delete|select) into a function
call running at the privs of its definer and writing the functions
that run at an elevated user.

-sc

--
Sean Chittenden

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

 
 
 

Overly zealous security of schemas...

Post by Sean Chittend » Mon, 28 Apr 2003 13:38:19


Quote:> > > And actually, it looks like sequences have this same problem as
> > > well, only things are slightly worse there: you have to grant
> > > SELECT,UPDATE to a sequence to the public in order for those to
> > > work automagically. :-/

> > That's always been true though.

> True, but while we're on the topic, I figured I'd give things a shot
> in the, could this be fixed dept.  Inserting into a view with a
> rule, the resulting query is run as the rule executor, not as the
> rule definer.  If that were somehow possible, then it'd remove the
> need to have a rule rewrite the (insert|update|delete|select) into a
> function call running at the privs of its definer and writing the
> functions that run at an elevated user.

Here's a little follow up on this post, here's an example of what I'm
trying to accomplish:

/* Begin example */
\c template1 pgsql
DROP DATABASE test;
CREATE DATABASE test WITH OWNER dba;

\c test dba
BEGIN;
CREATE SCHEMA s AUTHORIZATION dba;
CREATE TABLE s.f (i INT, PRIMARY KEY(i));
INSERT INTO s.f (i) VALUES (42);
CREATE TABLE s.t (i SERIAL, c INT, PRIMARY KEY(i));
ALTER TABLE s.t ADD FOREIGN KEY(c) REFERENCES s.f(i);

CREATE VIEW public.v AS SELECT c FROM s.t;

CREATE RULE t_ins AS
        ON INSERT TO public.v DO INSTEAD
        INSERT INTO s.t (c) VALUES (NEW.c);

REVOKE ALL ON SCHEMA s FROM PUBLIC;
GRANT SELECT ON public.v TO PUBLIC;
COMMIT;

\c test normal_user
INSERT INTO v VALUES (42);
/* End Example */

psql:test3.sql:30: ERROR:  s: permission denied

:-/ If you grant access to s, you get further along in the process:

-- As dba
GRANT USAGE ON SCHEMA s TO PUBLIC;

-- As normal_user
INSERT INTO v VALUES (42);
ERROR:  t_i_seq.nextval: you don't have permissions to set sequence t_i_seq

Still, :(.  So, if you grant access to the schema, and allow
SELECT,UPDATE on the sequence, then you're good to go:

-- As dba
GRANT SELECT,UPDATE ON s.t_i_seq TO PUBLIC;

-- As normal_user
INSERT INTO v VALUES (42);
INSERT 2126593 1

Whew.  Only problem is you have to know the name of all of the
sequences in use in the schema and open up access to the schema.  If
there was a way of executing a query generated by a RULE as the
definer, all of this would magically disappear... unless I'm missing
something.  It's possible to do the following to get around this
quirk, however it's really time consuming/error prone to do this with
tables with a large number of columns:

/* Begin */
\c test dba
CREATE FUNCTION public.t_ins(INT)
    RETURNS BOOL
    EXTERNAL SECURITY DEFINER
    AS 'BEGIN
        INSERT INTO s.t (c) VALUES ($1);
        RETURN TRUE;
END;' LANGUAGE 'plpgsql';

CREATE OR REPLACE RULE t_ins AS
        ON INSERT TO public.v DO INSTEAD
        SELECT public.v_ins(NEW.c);
GRANT EXECUTE ON FUNCTION public.t_ins(INT) TO PUBLIC;
/* End */

This is the only way that I've been able to get around giving access
to the public to schema s and sequence s.t_i_seq.  Does this use case
make sense for why it'd be great to have:

     CREATE OR REPLACE RULE t_ins EXTERNAL SECURITY DEFINER ON ...

Some food for thought I suppose given it changes the context of an
insert rather dramatically:

test=> INSERT INTO v VALUES (42);
 v_ins
-------
 t
(1 row)

Does this make sense?  Do you think having a function + rule for every
view is the correct way to get around the perm barrier or would it be
more appropriate to have a rule run the resulting query at an elevated
priv? -sc

--
Sean Chittenden

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

 
 
 

Overly zealous security of schemas...

Post by Sean Chittend » Mon, 28 Apr 2003 17:36:23


Quote:> > Ah, I had this backwards: I thought SECURITY DEFINER wasn't
> > setting something that'd allow the foreign keys to run as the
> > owner of the function.

> Nah; by the time the RI triggers run, you're out of the function
> entirely.  So they have to fend for themselves.

> Here's the 7.3 version of the patch (it's a bit ugly because I had
> to back-port a couple of changes that are in CVS tip).

Ah, excellent!  Thank you Tom.  This patch works wonderfully for me!
It doesn't apply cleanly to 7.2, but here's the diff in case anyone's
interested (applies to postgresql7 and postgresql-devel, just drop it
into files/ and recompile):

http://people.FreeBSD.org/~seanc/patches/patch_postgresql-7.3.2::src:...

-sc

--
Sean Chittenden

---------------------------(end of broadcast)---------------------------

 
 
 

1. XML Schemas and mapping schemas

Hi all,

From my reading, I've noticed most examples and references regarding mapping
schemas (for sql) refer to XDR (Microsoft's schema format called XML Data
Reduced). I'm hoping that someone can confirm whether SQLXML Webrelease 2
and the final release support XSD (XML Schemas as recommended by W3C) for
use in mapping schemas...

Thanks in advance,

Rein

2. advanced java networking chapter 5

3. slow and overly complicated views

4. What is the best way to backup logical logs ?

5. Overly Complex Simple Query

6. SQL on how to find row differences

7. Confused between Server Security and Database Security

8. connect access

9. associating front end security with back-end security

10. Use NT Security instead of SQL Security

11. 29056-MN-MINNEAPOLIS-Network Security-UNIX-ORACLE-AS400-Novell-UNIX AND ORACLE SECURITY

12. change from integrated security to nt only security

13. SQL security to NT security