On 2011-07-18 22:21, Kohei KaiGai wrote:
The Scientific Linux 6 is not suitable, because its libselinux version
is a bit older
than this patch expects (libselinux-2.0.99 or later).
My recommendation is Fedora 15, instead.
Installing right now, thanks for the heads up!
/etc/selinux/targeted/contexts/sepgsql_contexts: line 33 has invalid object
type db_blobs
It is not an error, but just a notification to inform users that
sepgsql_contexts
file contains invalid lines. It is harmless, so we can ignore them.
I don't think sepgsql.sgml should mention about this noise, because it purely
come from the problem in libselinux and refpolicy; these are external packages
from viewpoint of PostgreSQL.
This is in contradiction with the current phrase in the documentation
that's right after the sepgsql.sql loading: "If the installation process
completes without error, you can now start the server normally". IMHO if
there are warnings that can be ignored, it would limit confusion for
sepgsql users if the documentation would say it at this point, e.g. "If
the installation process completes without error, you can now start the
server normally. Warnings from errors in sepgsql_contexts, a file
external to PostgreSQL, are harmless and can be ignored."
The point of this patch is replacement of existing mechanism<...>
So, it is not necessary to define a new policy for testing.
Thanks for elaborating on this.
The security label is something like user-id or ownership/object-acl in the
default database access controls. It checks a relationship between user-id
and ownership/object-acl of the target object. If this relationship allowed
particular actions like 'select', 'update' or others, it shall be allowed when
user requires these actions.
In similar way, 'db_table:select' is a type of action; 'select' on table object,
not an identifier of user or objects.
SELinux defines a set of allowed actions (such as 'db_table:select') between
a particular pair of security labels (such as 'staff_t' and 'sepgsql_table_t').
The pg_seclabel holds only security label of object being referenced.
So, you should see /selinux/class/db_*/perms to see list of permissions
defined in the security policy (but limited number of them are in use, now).
The system's default security policy (selinux-policy package) defines all the
necessary labeles, and access control rules between them.
So, we never need to modify security policy to run regression test.
The sepgsql_trusted_proc_exec_t means that functions labeled with this label
is a trusted procedure. It switches security label of the user during
execution of
this function. It is a similar mechanism like SetExec or security
definer function.
The sepgsql_ro_table_t means 'read-only' tables that disallow any
writer operations
except for administrative domains.
You can define your own policy, however, I intend to run regression test
without any modification of the default security policy.
Thank you for this clarification. I have some ideas of things that if
they were in the documentation they'd helped me. Instead of seeking
agreement on each item, I propose that I gather documentation additions
in a patch later after the review, and leave it up to you guys whether
to include them or not.
regards,
Yeb
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
