REVISED PATCH [REVIEW:3-5,3-5-1] PostgreSQL regression wrt 3.5.0: privileges via groups
Lionel Elie Mamane
lionel at mamane.lu
Mon Feb 27 04:45:11 PST 2012
Forgot to regenerate the patch after last-minute fix before sending
email... Missing closing parenthesis in previous patch. New patch
On Mon, Feb 27, 2012 at 01:41:21PM +0100, Lionel Elie Mamane wrote:
> Attached patch fixes fdo#46675, a regression in 3.5.1rc1 wrt to 3.5.0
> introduced in the fix for fdo#45254. It is a backport of my
> corresponding commit in master; in 3.5.1 only getTablePrivileges is
> affected, not getColumnPrivileges.
> A PostgreSQL role can be member of another role. Think of the first
> role as a user and of the second role as a group; a role can be both a
> user and a group.
> PostgreSQL-SDBC in LibreOffice 3.5.1 leads the rest of the system to
> ignore privileges (permissions) given to a user via a group
> membership. This has the consequence that Base (e.g. in a form) won't
> allow the user to make things he is allowed to do: e.g. edit data,
> insert new data, ...: The corresponding UI elements are locked /
> greyed out, in the case that the user does not have that privilege
> directly, but "only" via a group membership.
> The bug has a testcase, but one needs a PostgreSQL server to test.
> The patch duplicates every privilege description line given to a role
> (group) for each member of that role, by doing a cross-product with
> every existing role, and restricting to rows such that the role is a
> member of the grantee group. PUBLIC is the special role "anyone".
> "pg_has_role(pr.oid, dp.grantee, 'USAGE')" is true if and only of
> pr.oid is a member of dp.grantee; it is false otherwise.
> Please apply to libreoffice-3-5 and libreoffice-3-5-1.
More information about the LibreOffice