Re: More sepgsql weirdness
Hi On Tue, Apr 13, 2021 at 6:22 PM Robert Haas wrote: > On Tue, Apr 13, 2021 at 10:33 AM Dave Page wrote: > > On a system with selinux and sepgsql configured, search path resolution > appears to fail if sepgsql is in enforcing mode, but selinux is in > permissive mode (which, as I understand it, should cause sepgsql to behave > as if it's in permissive mode anyway - and does for other operations). > Regardless of whether my understanding of the interaction of the two > permissive modes is correct, I don't believe the following should happen: > > I agree that this sounds like something which shouldn't happen if the > system is in permissive mode, I realised that my test database hadn't had the sepgsql SQL script run in it (I must have created it before running it on template1). I guess the error was caused by lack of proper labelling. So, clearly my fault, but I think there are a couple of things we need to do here: 1) Improve the docs for sepgsql. The *only* vaguely useful source of info I've found on using this is "SELinux System Administration", a Packt book by Sven Vermeulen. Our own docs don't even list the supported object classes (e.g. db_table) or types (e.g. sepgsql_ro_table_t) for example. 2) Improve the way we handle cases like the one I ran into. I only realised what was going on when I tried to run sepgsql_getcon() to confirm I was running in undefined_t. Clearly very weird things can happen if labelling hasn't been run; perhaps we could raise a notice if the sepgsql module is loaded but sepgsql_getcon() isn't present (though that seems flakey at best)? I'd hesitate to try to check for the presence of one or more labels as the admin could have intentionally removed them or changed them of course. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EDB: http://www.enterprisedb.com
Re: More sepgsql weirdness
On Tue, Apr 13, 2021 at 10:33 AM Dave Page wrote: > On a system with selinux and sepgsql configured, search path resolution > appears to fail if sepgsql is in enforcing mode, but selinux is in permissive > mode (which, as I understand it, should cause sepgsql to behave as if it's in > permissive mode anyway - and does for other operations). Regardless of > whether my understanding of the interaction of the two permissive modes is > correct, I don't believe the following should happen: I agree that this sounds like something which shouldn't happen if the system is in permissive mode, but I think the behavior itself is deliberate. See OAT_NAMESPACE_SEARCH and commit e965e6344cfaff0708a032721b56f61eea777bc5. -- Robert Haas EDB: http://www.enterprisedb.com
More sepgsql weirdness
On a system with selinux and sepgsql configured, search path resolution appears to fail if sepgsql is in enforcing mode, but selinux is in permissive mode (which, as I understand it, should cause sepgsql to behave as if it's in permissive mode anyway - and does for other operations). Regardless of whether my understanding of the interaction of the two permissive modes is correct, I don't believe the following should happen: mls=# SELECT current_user; current_user -- postgres (1 row) mls=# SHOW search_path; search_path - "$user", public (1 row) mls=# \dn+ public List of schemas Name | Owner | Access privileges | Description +--+--+ public | postgres | postgres=UC/postgres+| standard public schema | | =UC/postgres | (1 row) mls=# CREATE TABLE tb_users(uid int primary key, name text, mail text, address text, salt text, phash text); ERROR: no schema has been selected to create in LINE 1: CREATE TABLE tb_users(uid int primary key, name text, mail t... ^ mls=# CREATE TABLE public.tb_users(uid int primary key, name text, mail text, address text, salt text, phash text); CREATE TABLE mls=# drop table tb_users; ERROR: table "tb_users" does not exist mls=# drop table public.tb_users; DROP TABLE This is on head, pulled yesterday. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EDB: http://www.enterprisedb.com
