This example, taken from the Quest Privilege Manager Administrator's Guide, demonstrates how to create a new profile variable, pf_forbidusers, that you can use in any profile or shell profile. The customization will cause the profile selection to fail when the user is in the
pf_forbidusers list, even if the user matches pf_authusers. This would allow you to deny specific users from any profile or shell profile.
In addition, a enhancement request has been submitted, ID M#6514, to make this forbidden users list an option in the default profiles.
The following is an updated profile_customer_policy.conf file indicating the modifications in bold.
############################################################################
# Quest Privilege Manager for Unix Profile Policy V600 (XXX)
# Quest Software Inc. 2013
#
# Sample Default Policy Generated for QPM4U
#
# This policy is included by file: profileBasedPolicy.conf
#
# This allows customization at certain points while reading profiles. The
# following functions are provided:
# - fn_log_and_accept_custom
# - fn_custom_profile_init
# - pr_custom_profile_reset
# - fn_customer_init
############################################################################
# custom profile variables
pf_forbidusers={};
#########################################################################
# FUNCTION: fn_log_and_accept_custom
#
# This function is called by pr_log_and_accept to do any
# customer-specific actions required, just before accepting the request.
#
#########################################################################
function fn_log_and_accept_custom()
{
return true;
}
#########################################################################
# FUNCTION: fn_custom_profile_init
# Do any custom config required for a profile.
# This is called after matching user/group to a profile,
# but before checking anything else.
#########################################################################
function fn_custom_profile_init()
{
if (user in pf_forbidusers)
return false;
return true;
}
#########################################################################
# PROCEDURE: pr_custom_profile_reset
# Reset any custom variables after processing a profile
#########################################################################
procedure pr_custom_profile_reset()
{
#reset these for each profile read
pf_forbidusers={};
return;
}
#########################################################################
# FUNCTION: fn_customer_init
# Do any custom config required for the policy
# This is called before processing any profiles.
#########################################################################
function fn_customer_init()
{
return true;
}
The initial definition of the variable (pf_forbidusers={};) is near the top of the file. In order to be globally accessible, the variable must be defined outside of any function or procedure call. The same statement is also in the pr_custom_profile_reset() procedure so that the variable is reset before a new profile (or shell profile) is read. Finally, some code was added to fn_custom_profile_init() to return false if the user is listed in the variable.
If you add the following to the demo profile, user jbloggs would no longer able to successfully run pmrun
id using that profile:
pf_forbidusers={"jbloggs"};