Re: Port Reports: UnixWare/Failure/Priviledge Test

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Larry Rosenman <ler(at)lerctr(dot)org>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Port Reports: UnixWare/Failure/Priviledge Test
Date: 2003-10-29 20:26:39
Message-ID: 19968.1067459199@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Okay, the cause of the permissions regression failure is this:

Larry is running the regression tests as a superuser, but not as the
original postgres superuser. This means that when the privileges
regression test does

REVOKE ALL PRIVILEGES ON LANGUAGE sql FROM PUBLIC;

nothing happens, because the revoke is implicitly assumed to mean
"revoke whatever privileges I granted", and Larry's superuser hasn't
granted any. The public privileges on language SQL were granted by
user postgres, and they remain in force. So the later CREATE FUNCTION
that the test expects to fail, succeeds.

Is this a bug, or is it correct-per-spec behavior? It's surely likely
to confuse people. I wonder whether superusers shouldn't be allowed to
revoke privileges granted by other people. As the code stands, they
cannot.

If it isn't a bug, I think we'll have to document that the privileges
regression test fails when you run it as a non-original superuser. Ugh.

I've also found some corner-case bugs in ACL manipulation that arise
from the fact that Peter changed the code to allow zero-length ACL
arrays; seems he missed one or two consequences of that change. Will
fix these, but it doesn't affect the main issue.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Larry Rosenman 2003-10-29 20:35:06 Re: Port Reports: UnixWare/Failure/Priviledge Test
Previous Message Manfred Spraul 2003-10-29 17:45:24 Re: O_DIRECT in freebsd