Heikki Linnakangas wrote:
This seems to be a recurring theme with this patch. We stripped
row-level permissions, now we have SET/SHOW and the "function
installation" permissions. And the read/write file permissions. To make
progress, we need to consider each new feature like that separately, as
separate patches.
KaiGei: Let's drop SET/SHOW permissions from the patch, I presume that's
not critical for the overall goal.
OK, its significance is relatively low.
Dropping the "function installation" permissions would simplify the
patch a lot. It would make the patch as whole a lot easier to swallow.
Let's ask the same question as with the row-level permissions: If we
drop the function installation stuff, would the rest of the patch still
be useful? We can revisit that part in the future.
As far as we have the idea of "superuser" permission on SELinux also,
we can do it later.
I have the same concern as Tom about trying to curtail what superusers
can do. We have not been concerned about what a superuser can and can't
do before, so there could be small loopholes all over the codebase that
we haven't thought about. Just as an example, you added checks to COPY
to prevent reads from/writes to files. That's restricted to superusers.
However, you left pg_read_file() in src/backend/utils/adt/genfile.c wide
open.
Oops, it was my overlooks.
If we drop the goal of trying to restrict what a superuser can do, is
the patch still useful?
I want to keep permission checks on files specified by users, because
the "superuser" permission affects very wide scope, and all or nothing
policy in other word.
However, the combination of clients and files is not so simple, and
I think it is necessary to apply permission checks individually.
I can agree to postpone the checks for procedure installation,
C-libraries installation/loading.
One idea is to add a single "is superuser" permission to sepgsql. That
can be checked in a single place: superuser_arg(). If SE-Linux says that
you don't have superuser permissions, then superuser() will return false
even if the current user is marked as a superuser in pg_role. It would
give the same level of protection as sprinkling those fine-grained
checks all over the code, just in a more coarse-grain fashion.
At least, I think it is not a strange design.
In-kernel SELinux also has similar permission (capability class) to
restrict root privileges, in additon to the invididual checks.
(NOTE: In Linux, root privilges is a set of capability.)
Maybe, I can submit the revised patch within 1.5 days.
Please wait for a while.
Thanks,
--
KaiGai Kohei <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
