Sarah Jelinek wrote:
>> oh really? Maybe that is a supported scenario then (per Shawn's
>> scenario?)
>> If this is the case, then shouldn't the user be able to login with a
>> null
>> password, or does it not work like that?
> Unless I am looking at the original code incorrectly, it looks like we
> created the user name entry, and if the password data was null we just
> put a warning in the log. That was a possibility in the original code
> path.
Are you just look at the code that adds it to the nvlist. The function
that processes this list downstream is liborchestrator::om_perform_install()
It looks like if a username is given, but no userpass, it uses a default
user password:
if (nvlist_lookup_string(uchoices,
OM_ATTR_USER_PASSWORD, &upasswd) != 0) {
/* Password not specified, use default value */
upasswd = OM_DEFAULT_USER_PASSWORD;
And OM_DEFAULT_USER_PASSWORD is the empty string ""
So I think you're right, a user is set up with an empty string as the
password for this scenario.
>
> I thought the user should be able to login with a null password, but
> the graphical login wouldn't let me. It kept error'ing out.
>>
>> If we keep this scenario, then the code downstream which turns root into
>> a role should be triggered off the existence of both, a username and a
>> userpass, not just the username. That code is in
>> libict::ict_set_user_role()
>>
>>
> Why would we change this based on a user password? It seems to me root
> should still be a role if the user has entered a user in the sc file,
> even without a password. Presumably they have a plan for this
> scenario. If we allow this scenario.
Yeah, I guess I can possibly see this.
-ethan
