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