Thread: Re: NO-CREATE-TABLE and NO-LOCK-TABLE
Applied. I had a little trouble getting the patch to apply cleanly. Seems some code has moved, and the patch actually put it in the wrong place in two cases. The context wasn't large enough. I think I got them all in the right place. Thanks. > > Hi, > > I have large database and with this DB work more users and I very need > more restriction for fretful users. The current PG allow define only > NO-CREATE-DB and NO-CREATE-USER restriction, but for some users I need > NO-CREATE-TABLE and NO-LOCK-TABLE. > > This patch add to current code NOCREATETABLE and NOLOCKTABLE feature: > > CREATE USER username > [ WITH > [ SYSID uid ] > [ PASSWORD 'password' ] ] > [ CREATEDB | NOCREATEDB ] [ CREATEUSER | NOCREATEUSER ] > -> [ CREATETABLE | NOCREATETABLE ] [ LOCKTABLE | NOLOCKTABLE ] > ...etc. > > If CREATETABLE or LOCKTABLE is not specific in CREATE USER command, > as default is set CREATETABLE or LOCKTABLE (true). > > A user with NOCREATETABLE restriction can't call CREATE TABLE or > SELECT INTO commands, only create temp table is allow for him. > > It is interesting for PG? > > > Karel > > PS. When will take out from freezer current 7.0? Content-Description: [ application/x-gzip is not supported, skipping... ] -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Fri, 9 Jun 2000, Bruce Momjian wrote:
> Applied. I had a little trouble getting the patch to apply cleanly.
> Seems some code has moved, and the patch actually put it in the wrong
> place in two cases. The context wasn't large enough. I think I got
> them all in the right place.
Hmm, a question is if this patch will have long lifetime. Possible is that
new ACL (etc.) implement some features from this patch.
But, I mean that CREATE TABLE restriction is needful in large multiuser
projects.
BWT. --- if Peter implement new ACL, I plan 'CREATE PROFILE' feature for
better user control (connection idle time, default ACL mask
...etc.).
Thanks.
Karel
> > On Fri, 9 Jun 2000, Bruce Momjian wrote: > > > Applied. I had a little trouble getting the patch to apply cleanly. > > Seems some code has moved, and the patch actually put it in the wrong > > place in two cases. The context wasn't large enough. I think I got > > them all in the right place. > > Hmm, a question is if this patch will have long lifetime. Possible is that > new ACL (etc.) implement some features from this patch. > > But, I mean that CREATE TABLE restriction is needful in large multiuser > projects. > > BWT. --- if Peter implement new ACL, I plan 'CREATE PROFILE' feature for > better user control (connection idle time, default ACL mask > ...etc.). Well, we clearly need ability to prevent table creation, and lock control is good too. Seems useful. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian writes: > Well, we clearly need ability to prevent table creation, and lock > control is good too. Seems useful. Lock control needs to be per table, not user. Creation control needs to be per database (eventually schema), not user. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
[ Charset ISO-8859-1 unsupported, converting... ] > Bruce Momjian writes: > > > Well, we clearly need ability to prevent table creation, and lock > > control is good too. Seems useful. > > Lock control needs to be per table, not user. Creation control needs to be > per database (eventually schema), not user. > I agree. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Sun, 11 Jun 2000, Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Well, we clearly need ability to prevent table creation, and lock
> > control is good too. Seems useful.
>
> Lock control needs to be per table, not user. Creation control needs to be
> per database (eventually schema), not user.
>
We already tell about it, but yes, you are right too. But it is not
implemented yet.
Karel
> > On Sun, 11 Jun 2000, Peter Eisentraut wrote: > > > Bruce Momjian writes: > > > > > Well, we clearly need ability to prevent table creation, and lock > > > control is good too. Seems useful. > > > > Lock control needs to be per table, not user. Creation control needs to be > > per database (eventually schema), not user. > > > > We already tell about it, but yes, you are right too. But it is not > implemented yet. > I am inclined to think it helps to have this configurable at the user level too, but let's see what people come up with. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> >
> > We already tell about it, but yes, you are right too. But it is not
> > implemented yet.
> >
>
> I am inclined to think it helps to have this configurable at the user
> level too, but let's see what people come up with.
Yes, I too, but it is the good theme for flame-war, all can have right.
For example user that is used for web-server connection needs only
small privilage (SELECT) and why for _all_ tables run GRANT if I can set it
as global option.
I very expect new ACL, because I'm admin for large DB with critical data
and with more sub-admins and users and groups (..etc.) and I need good
tools for user restriction/control.
And implement all oneself via triggers (columns privilage) is very
difficult.
Karel