David Gaines wrote:
> Sorry if I misled you. For now I edit the prof_attr and exec_attr files in
> /etc/security. Therefore I have to go to each system and replace these files
> with my edited copies. As far as I know there is no solution. I?m hoping it
> is fixed in the next release of Solaris. Sorry I couldn't be more help.
>
>
> This message posted from opensolaris.org
> _______________________________________________
> security-discuss mailing list
> security-discuss at opensolaris.org
>
I'm pretty sure that the ldapaddent problems are a known bug:
4622166 ldapaddent does not add services with "+" in the name
When I tried to add the following exec_attr entry:
All:solaris:act:::*;*;*;*;*:
I could trace through ldapaddent and see that it is creating the following
DN for the new LDAP object:
cn=All+SolarisKernelSecurityPolicy=solaris+SolarisProfileType=act+SolarisProfileId=*;*;*;*;*,ou=SolarisProfAttr,dc=sun,dc=com
This is not valid LDAP syntax; semicolons are an alternate character
for separating the RDN components of the DN, equivalent to commas.
ldapaddent needs to apply proper escaping to DNs that contain special
characters. (RFC 2253 section 2.4)
I tried an experiment to see if the TX exec_attr mechanism for CDE actions
works after forcing the correct data into the LDAP database:
1) Create /usr/dt/appconfig/types/C/TestAction.dt as follows:
ACTION TestAction
{
LABEL TestAction
TYPE COMMAND
EXEC_STRING /usr/dt/bin/dtterm
ICON Dtactn
WINDOW_TYPE NO_STDIO
}
2) Create a test profile "Test Profile" that contains this action.
I was able to load the prof_attr with ldapaddent, but had to load
the exec_attr with ldapadd and hand-edited LDIF:
% ldaplist -l prof_attr 'Test Profile'
dn: cn=Test Profile,ou=SolarisProfAttr,dc=sun,dc=com
objectClass: SolarisProfAttr
objectClass: top
cn: Test Profile
SolarisAttrKeyValue: help=TestProfile.html
SolarisAttrLongDesc: Special profile for testing
dn: cn=Test
Profile+SolarisKernelSecurityPolicy=solaris+SolarisProfileType=act+SolarisProfileId=TestAction\;*\;*\;*\;*,ou=SolarisProfAttr,dc=sun,dc=com
objectClass: top
objectClass: SolarisProfAttr
objectClass: SolarisExecAttr
cn: Test Profile
SolarisKernelSecurityPolicy: solaris
SolarisProfileType: act
SolarisProfileId: TestAction;*;*;*;*
SolarisAttrReserved1:
SolarisAttrReserved2:
SolarisAttrKeyValue: privs=zone
3) Add "Test Profile" to my account, logout/login so all the CDE databases
get reloaded, and run "dtaction TestAction". The terminal that appeared
had "privs=zone". This proves that CDE actions can be launched with the
exec_attr entries from LDAP applied, if they can be loaded in the first
place. So, the TX parts of this seem to work correctly.
I'm not sure about the problems with SMC, but they are probably
a separate issue and not related to ldapaddent.
