[refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)
Chris PeBenito
pebenito at gentoo.org
Tue Aug 17 13:00:50 CDT 2010
On 08/16/10 19:37, KaiGai Kohei wrote:
> (2010/08/17 4:42), Christopher J. PeBenito wrote:
>> On 08/16/10 05:11, KaiGai Kohei wrote:
>>> Sorry for this long silent on the topic.
>>>
>>> IIRC, we have already agreed most part of the patch, haven't we?
>>>
>>> - The dbadm_t domain shall be launched via sudo, not a login shell,
>>> so, userdom_base_user_template() is used to grant basic privileges
>>> to dbadm_t instead of userdom_unpriv_user_template().
>>> - It allows too much privileges to dbadm_t, if we allows him to launch
>>> setfiles, so we removed seutil_domtrans_setfiles().
>>>
>>> Did we have any more issues?
>>>
>>> The attached patch is same as the last version except for it was rebased
>>> to the latest reference policy.
>>
>> I only have two issues:
>>
>> 1. Why should dbadm be allowed to set enforce mode?
>
> It uses selinux_get_enforce_mode(), not selinux_set_enforce_mode().
> We just allow dbadm_t to see the current working mode.
My mistake, I misread it. You're right, its fine.
>> 2. Why does dbadm need to manage generic locks?
>
> It was originally copied from webadb.te, but PostgreSQL also makes
> its lockfile on the /var/lock/subsys/postgresql. If server process
> unexpectedly crashed, dbadm_t need to remove it by hand, doesn't it?
Based on what I see in the policy, my guess is this file is created by
the init script, right? If not, then it sounds like PostgreSQL needs a
lock type.
I'd rather it just have delete permissions, rather than full manage
permissions. Something like files_delete_all_locks(), but for
var_lock_t instead.
> Thanks,
>
>> After those are resolved, it can be merged.
More information about the refpolicy
mailing list