[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:41:21 PST 2012
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