
Hello

I like the added security of 6.3 however how do you grant access to 
SELECT currval('SEQ') AS id
I get a permission error on seq.currval?

I figured out how to use CVSUP so I am grabbing the latest version.

If this is fixed in it then great otherwise any ideas?

Michael

* Michael J. Rogan,  Network Administrator,   905-624-3020 *
* Mark IV Industries, F-P Electronics & I.V.H.S. Divisions *
* mrogan@fpelectronics.com                 mrogan@ivhs.com *

Wed, 25 Feb 1998 17:01:24 +0000
"Michael J. Rogan" <mrogan@fpelectronics.com>
SELECT currval('SEQ') broken?

Compiles, installs and tests cleanly...regression test results are in
src/test/regress/regression.Solaris-Sparc for anyone wanting to look at
the variances...




Wed, 25 Feb 1998 15:55:46 -0500 (EST)
The Hermit Hacker <scrappy@hub.org>
Very nice... Solaris/Sparc works...
Michael J. Rogan wrote:
> 
> Hello
> 
> I like the added security of 6.3 however how do you grant access to
> SELECT currval('SEQ') AS id
> I get a permission error on seq.currval?
> 
> I figured out how to use CVSUP so I am grabbing the latest version.
> 
> If this is fixed in it then great otherwise any ideas?

I don't remember - did we NO_ACCESS to a table for public
as default or not ?
If yes then you have to GRANT permissions on sequences...

Vadim

Thu, 26 Feb 1998 06:21:15 +0700
"Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>
Re: [HACKERS] SELECT currval('SEQ') broken?
> 
> Michael J. Rogan wrote:
> > 
> > Hello
> > 
> > I like the added security of 6.3 however how do you grant access to
> > SELECT currval('SEQ') AS id
> > I get a permission error on seq.currval?
> > 
> > I figured out how to use CVSUP so I am grabbing the latest version.
> > 
> > If this is fixed in it then great otherwise any ideas?
> 
> I don't remember - did we NO_ACCESS to a table for public
> as default or not ?

    We did so. Default is now NO_ACCESS for public but SELECT
    granted for public on IsSystemRelationName() where no
    explicit ACL is set. So all tables and views prefixed pg_
    are readable by default and must still be revoked if you
    don't want them public readable. All other tables and
    views are private.
    

> If yes then you have to GRANT permissions on sequences...

    Checked that and it works. The creator of the sequence is
    the owner and can do anything by default (superuser too). 

    GRANT SELECT ON seq permitts to get currval() from sequence.

    GRANT SELECT, UPDATE ON seq permitts to get nextval().


    Great to see that new security code works also for an area
    that we didn't thought about.


Jan

-- 

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #


Thu, 26 Feb 1998 07:55:20 +0100 (MET)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] SELECT currval('SEQ') broken?
On Thu, 26 Feb 1998, Vadim B. Mikheev wrote:

> Michael J. Rogan wrote:
> > 
> > Hello
> > 
> > I like the added security of 6.3 however how do you grant access to
> > SELECT currval('SEQ') AS id
> > I get a permission error on seq.currval?
> > 
> > I figured out how to use CVSUP so I am grabbing the latest version.
> > 
> > If this is fixed in it then great otherwise any ideas?
> 
> I don't remember - did we NO_ACCESS to a table for public
> as default or not ?

	Yes...

Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Thu, 26 Feb 1998 17:38:27 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] SELECT currval('SEQ') broken?