Joe, To be clearer, if there are missing passwords in either a user-supplied SC manifest or default.xml (which supplies the default user, user password, and root password), the installation will fail. William
Joseph J. VLcek wrote: > William, > > Sounds good to me. My brief comment below. > > Joe > > William Schumann wrote: >> Joe, >> >> Joseph J VLcek wrote: >>> William Schumann wrote: >>>> Default values for user and root passwords were not encrypted as >>>> called for in: >>>> >>>> - 4246 The user and root password are not encrypted in SC manifest >>>> >>>> http://cr.opensolaris.org/~wmsch/bug-6622/ >>>> http://defect.opensolaris.org/bz/show_bug.cgi?id=6622 >>>> >>>> Edited default.xml in SUNW-installadm-tools to provide usable >>>> encrypted passwords as described in bug report. >>>> >>>> user: jack password:jack >>>> root password: opensolaris >>>> >>>> Also added code to provide the same values if they are absent from >>>> the SC manifest for whatever reason. >>>> >>>> Informational debugging message in Orchestrator can now display the >>>> passwords, since they are encrypted. >>>> >>>> Tested default.xml changes going into SUNWinstalladm-tools package >>>> on x86 and SPARC. >>>> Tested new auto-install and liborchestrator on x86 and SPARC. >>>> Deleted entries from SC manifest and software generated correct >>>> default values. >>>> _______________________________________________ >>>> caiman-discuss mailing list >>>> caiman-discuss at opensolaris.org >>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>> >>> >>> William, >>> >>> Set the commit comment prior to generating the webrev. (I used to >>> forget to do this too. ;) >>> >>> Everything looks good... >>> >>> Just some nits. >>> >>> Hope this helps! >>> >>> Joe >>> >>> usr/src/cmd/ai-webserver/default.xml >>> ++++++++++++++++++++++++++++++++++++ >>> >>> Suggestion, Please consider: >>> ---------------------------- >>> >>> Is it considered safe to store encrypted defaults? >> Well, I suppose that it's a usability question. It is not safe for >> an uninformed user; however, many current users are evaluating AI and >> do not want to have to go through the process of generating passwords >> and placing them in manifests. Those concerned with maximum security >> will change the passwords in the manifest, protect manifests from >> public view, and change the passwords upon reboot. >>> What if the encryption algorithm changes? >> AI controls the encryption algorithm via /etc/security/policy.conf. >> If the security policy were changed in the distro, the default.xml >> passwords would also have to be changed to work. >>> >>> Since you added code to provide the defaults perhaps it might be >>> safest to not list the encrypted defaults in the manifest. >> Again, it is inherently unsafe to provide default passwords whether >> they are encrypted or not. It is assumed that the concerned user >> will override the defaults. Perhaps it is a bad idea to have the >> defaults in the code: if the default passwords are not provided in >> the code, the passwords could be removed from default.ini on the >> server so that there are no defaults at all (although I don't think >> this would be standard practice.) A custom distro could also have >> the default passwords removed. >> >> So, I am backing out the embedded passwords in the code, so that if >> passwords are not provided in a manifest, the install will fail. I >> also backed out the logging statements exposing the encrypted >> passwords in the log at an informational logging level. What do you >> think? > > This seems to me to be the correct thing to do. > > >>> >>> Question: >>> --------- >>> >>> Do/should we provide a mechanism or instructions for a user to >>> generate the encrypted passwords if they want something besides the >>> defaults? >> I have already provided instructions for this in the AI setup HTML >> page and the design document. >>> >>> usr/src/cmd/auto-install/auto_install.c >>> +++++++++++++++++++++++++++++++++++++++ >>> >>> Comments on line 580 and 598 are the same. 598 should be changed from: >>> 598 /* load user name from manifest or 'jack' */ >>> >>> To: >>> 598 /* load user login name from manifest or 'jack' */ >>> >> Changed. >> >> Thanks, Joe. Please review the modifications. >> William >
