Bugzilla – Bug 4246
The user and root password are not encrypted in SC manifest
Last modified: 2009-02-08 13:05:37 UTC
You need to log in before you can comment on or make changes to this bug.
The SC manifest has the user and root passwords. It works if the passwords are in clear. If I try encrypted password, it doesn't work. The passwords should be encrypted. Example of a SC manifest <!-- <?xml version='1.0'?> <!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1"> <service_bundle type="profile" name="name"> <service name="ai_properties" version="1" type="service"> <instance name="default" enabled="true"> <property_group name="ai" type="application"> <propval name="username" type="astring" value="jack"/> <propval name="userpass" type="astring" value="jack"/> <propval name="description" type="astring" value="Jackshome"/> <propval name="rootpass" type="astring" value="opensolaris"/> <propval name="timezone" type="astring" value="US/Pacific"/> </property_group> </instance> </service> </service_bundle>
The AI engine is encryting the password and pass it to the orchestrator since orchestrator assumes that the password is encrypted. We should ask the user to provide encrypted passwords for user and root and shouldn't encrypt in AI engine.
Reducing the severity from blocker to critical since this bug doesn't affect the installation
Hi Alok, I just would like to give you a heads up to please ensure any special characters which can be valid XML markup use their XML entities instead.
(In reply to comment #3) > Hi Alok, > I just would like to give you a heads up to please ensure any special > characters which can be valid XML markup use their XML entities instead. The man page for shadow(4), which holds the encrypted passwords, indicates that the format of /etc/shadow is ASCII, so there should be no need for encoding XML entities for the encrypted passwords in the manifest. So it seems that the only change is to remove calls encrypting passwords in the AI engine.
(In reply to comment #4) > (In reply to comment #3) > > Hi Alok, > > I just would like to give you a heads up to please ensure any special > > characters which can be valid XML markup use their XML entities instead. > > The man page for shadow(4), which holds the encrypted passwords, indicates that > the format of /etc/shadow is ASCII, so there should be no need for encoding XML > entities for the encrypted passwords in the manifest. But there might be special XML characters in encrypted passwords that have alternate encodings in XML, so this must still be examined.
XML entities will now be decoded. The XML decoding is basic and has some shortcuts, such as decoding only 1-byte numeric values. It is expected that the AI manifests will soon be restructured and then should be parsed with established parsers, such as in libxml2. Bugs fixed along the way: - values with spaces were being truncated at the first space - apostrophes used as value delimiters were not working - some typos with keyword name not matching intended storage variable name
The man page for shadow(4) states: The encrypted password consists of at most CRYPT_MAXCIPHERTEXTLEN characters chosen from a 64-character alphabet (., /, 0-9, A-Z, a-z). Two additional special char- acters, "$" and ",", can also be used and are defined in crypt(3C). Since none of these characters are HTML entities, decoding is unnecessary.
(In reply to comment #7) > The man page for shadow(4) states: > > The encrypted password consists of at most > CRYPT_MAXCIPHERTEXTLEN characters chosen from a 64-character > alphabet (., /, 0-9, A-Z, a-z). Two additional special char- > acters, "$" and ",", can also be used and are defined in > crypt(3C). > > Since none of these characters are HTML entities, decoding is unnecessary. XML entities, that is.
Pushed in changeset 436:86bc65bc6cb6