Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE

On Tue, 29 Feb 2000, Peter Eisentraut wrote:

> > My suggestion for PG's priv./accounts:
>
> Great, as I said, I've been meaning to look into this. I'd be happy to
> hear any "demands".
>
> > - read-only account
>
> Just don't give anyone write permissions to anything. Unix doesn't have
> read-only accounts. I'm not so excited about non-orthogonal privileges.
>
> > - disable account (oracle: ACCOUNT LOCK)
>
> Hmm, that sounds reasonable.
>
> > - create table priv.
>
> On its way. ;)
>
> > - user's quotas (but without tablespace?)
>
> Probably very hard to do. The day you started using a relational database
> you largely gave up on tightly controlling storage constraints. See the
> never ending debate on 2x disk usage on drop column. Certainly useful,
> though.
>
> > - (dis)allow create functions/opretors/trigers
>
> Could/should be integrated in grant create.
>
> > - (dis)allow create user
> > ? (dis)allow change system tables
>
> Exist already.
>
> > 3/ ? - remove current hda.conf to system catalogs
>
> Won't work. The postmaster must authenticate the user before the database
> starts up. Well, it doesn't absolutely have to but redesigning that would
> be a pain.
>
> > - CONNECT_TIME
> > - IDLE_TIME
>
> Interesting. That would probably require a lot of work, though.
>
> > - PASSWORD_LIFE_TIME
>
> Got that.

I said about a PROFILE, it is more flexible than current simple CREATE USER.

>
> > - PASSWORD_VERIFY_FUNCTION (trust/password/kerberos..)
> > - ..etc
> > (- CPU SPENTING ?)
>
> > 5/ acl mask - default privilege for new table
>
> Definitely.
>
>
> Seems like we have a full bag of plans. Let's argue it out! ;)

I not only want new features and send suggestion, I can help with "full
bag of plans". But it is really great work and I not sure if is possible
create it as one-man project, it needs consensus between developers. If you
plan make changes to acl/account code it must be non-isolate change (it
must include user-profiles ..etc). (IMO of course :-)

A question: who is not user account defined for db and is it global? The
global account is probably not a problem, a problem is account settings.
IMHO is better use global account in 'pg_shadow' (with passwords, basic
options ..) and non-global 'pg_accountoption' in specific DB (with
CONNECT_TIME, IDLE_TIME, acl_mask ...etc.). This concept is better
extendable...

(We have free hands for this, it is not in SQL92 :-))

Karel