(2010/04/12 23:09), Christopher J. PeBenito wrote: > On Fri, 2010-04-09 at 14:29 +0900, KaiGai Kohei wrote: >> (2010/04/08 21:15), Daniel J Walsh wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> As Dominick stated. I prefer to think in terms of two different roles. >>> Login Roles, and Roles to execute in when you have privileges (IE Root). >>> >>> Login Roles/Types >>> staff_t, user_t, unconfined_t, xguest_t, guest_t >>> >>> Three interfaces can be used to create confined login users. >>> >>> userdom_restricted_user_template(guest) >>> userdom_restricted_xwindows_user_template(xguest) >>> userdom_unpriv_user_template(staff) >>> >>> >>> Admin Roles/Types >>> logadm_t, webadm_t, secadm_t, auditadm_t >>> >>> The following interface can be used to create an Admin ROle >>> userdom_base_user_template(logadm) >>> >>> >>> sysadm_t is sort of a hybrid, most people use it as an Admin Role. >>> >>> >>> I imagine that you login as a confined user and then use sudo/newrole to >>> switch roles to one of the admin roles. >> >> The attached patch revises roles/dbadm.te (to be applied on the upstream >> reference policy). It uses userdom_base_user_template() instead of the >> userdom_unpriv_user_template(), and should be launched via sudo/newrole. >> In the default, it intends the dbadm_r role to be launched by staff_r role. > > Why does dbadm need to run setfiles? The database files (typically, /var/lib/(se)?pgsql/*) have to be labeled correctly, so I thought dbadm needs to run setfiles. However, as long as they initialize database files using init script, initrc_t domain performs this initial labeling, so it might not be necessary. On the other hand, PostgreSQL support a feature to use multiple disks within a single database instance for performance utilization. (Called TABLESPACE; I don't know whether MySQL has such a feature.) http://archives.postgresql.org/pgsql-general/2006-08/msg00142.php It requires administrators to assign proper security context on the secondary directory, or to mount the secondary disk with context='...' option. Is there any good idea? Or, it should not be a task for dbadm? > Use of staff_role_change_to() is not allowed upstream. If staff should > be allowed to change to dbadm, the dbadm_role_change() should be used in > the staff module. OK, I'll fix it. Thanks, -- KaiGai Kohei <kaigai@xxxxxxxxxxxxx> -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
