ACL's

I think it should stay that way - being able to deny oneself a privilege is a
good way to make sure that one does what one does consciously. I know the
root password on many machines, but I still do almost everything through a
normal account - that way I have to make a conscious decison to become
dangerous :-) and if I accidentaly try to do something dangerous as an
ordinary user a) it doesn't happen and b) I'm reminded how dangerous it is.
I still have the ability to do dangerous things, I just have to take an extra
step.

I agree with your point regarding RULE permission and GRANT ALL; however,
GRANT ALL really should grant ALL, don't you think? Maybe add a variant
"GRANT NORMAL", where "NORMAL" is a mask of permissions set by the
administrator (of the given database of course).

Regards, K.

Am 21-Oct-98 schrieb Jan Wieck:

Hi,

while writing the chapter about Rules and permissions I
remember that there was a problem with non privileged users.
As soon as someone without superuser privs does a GRANT or
REVOKE on his relations, he must GRANT explicitly to himself
too or will get a "permission denied". I think since the
table owner allway has the right to change ACL's, this
doesn't make sense. I'll dig it up and send in a patch soon.

While doing this, should I exclude RULE permission from GRANT
ALL? I think it's dangerous to have it included, because the
usual way to give full access is a GRANT ALL and someone
might forget that this includes the right to disable rule
actions for a moment. The output of pg_rules gives anyone the
knowledge to reinstall the correct rules after. An explicitly
required GRANT RULE is better IMHO. And the RULE right isn't
standard, is it?

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) #

---
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (auer@kom.id.ethz.ch) Geschaeft/work +41-1-6327531
Kommunikation, ETHZ RZ Privat/home +41-1-4517941
Clausiusstrasse 59 Fax +41-1-6321225
CH-8092 ZUERICH Switzerland

[Charset iso-8859-1 unsupported, filtering to ASCII...]

I think it should stay that way - being able to deny oneself a privilege is a
good way to make sure that one does what one does consciously. I know the
root password on many machines, but I still do almost everything through a
normal account - that way I have to make a conscious decison to become
dangerous :-) and if I accidentaly try to do something dangerous as an
ordinary user a) it doesn't happen and b) I'm reminded how dangerous it is.
I still have the ability to do dangerous things, I just have to take an extra
step.

What do other DB's do. I assume they give the owner permission.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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

[Charset iso-8859-1 unsupported, filtering to ASCII...]

I think it should stay that way - being able to deny oneself a privilege is a
good way to make sure that one does what one does consciously. I know the
root password on many machines, but I still do almost everything through a
normal account - that way I have to make a conscious decison to become
dangerous :-) and if I accidentaly try to do something dangerous as an
ordinary user a) it doesn't happen and b) I'm reminded how dangerous it is.
I still have the ability to do dangerous things, I just have to take an extra
step.

What do other DB's do. I assume they give the owner permission.

Hmmm... so it's a TODO for 6.5 after beeing discussed.

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) #