[refpolicy] Adding support for the vlock program

[cpebenito@tresys.com (Christopher J. PeBenito)]

On 11/02/10 03:53, Dominick Grift wrote:
> On Tue, Nov 02, 2010 at 07:17:26AM +0000, HarryCiao wrote:
>>
>> Hi Chris,
>>
>>> Date: Mon, 1 Nov 2010 11:28:30 -0400
>>> From: cpebenito at tresys.com
>>> To: harrytaurus2002 at hotmail.com
>>> CC: domg472 at gmail.com; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Adding support for the vlock program
>>>
>>> On 10/30/10 07:38, TaurusHarry wrote:
>>>> Hi Dom and Christ,
>>>>
>>>> The attached is the v3 vlock.pp compliant with refpolicy coding style,
>>>> tests passed.
>>>>
>>>> Is it good enough for upstream? :-)
>>>
>>> Merged.  I renamed the interfaces, and did a little reordering in the TE
>>> file.  Is there any reason not to allow other admins (secadm, auditadm,
>>> etc.) to run vlock?
>>>
>>
>> Many thanks for wrapping up the vlock.pp! I am very happy to get a chance to contribute something back to this mailing list.
>>
>> Well, you've got me! Yes, we should have had the auditadm and secadm able to use the vlock program, along with sysadm, staff or unprivileged user. I used to call the vlock_run() in the userdom_common_user_template() (to grant access of vlock to all users in an once-and-for-all way), but got suggested that we should call the run interfaces in the roles/ layer, I just forgot to patch the auditadm and secadm to make them able to use vlock.
>>
>> Well, please find the patch in the attachment, tests passed. Thanks again!
> 
> I did not mention those "other" admins because in my vision those should not be login users in the first place.

They still can run in the console if you newrole to them, so they could
still want to lock the console.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com