Hi Gary,
thank you very much for review,
please see my response in line.
Jan
On 03/17/11 12:07 AM, Gary Winiger wrote:
On 03/16/11 07:36, Jan Damborsky wrote:
Hi,
I would appreciate review of draft design
for unconfiguration of user/root account.
Looks good to me. I skimmed b and c as well. Also
a couple comments.
useradd in the current gate should be able to create
zfs home directories and auto_mount maps by default.
Yep, I have noticed that when playing with useradd for
purposes of this project.
Currently, start method system/config smf service takes care
of that, but I think it might make sense to delegate that task
to useradd now when it provides for that features.
Though we will have to give it some thoughts, as looking at
useradd(1m) man page, unlike system/config, it does not provide
for customizing those parameters (e.g. name of ZFS dataset,
entry in /etc/auto_home).
Which might or might not be an issue.
1265957 usermod add encrypted password needs to
not take the password from the command line, or from
an environment variable. Both are technically violations
of policy. It can certainly read it from a read protected
file. root:root 600.
Thank you for pointing this out. I have updated that CR
with this information.
While shadow(4) syntax is considered stable, the contents
of the various fields is not -- and in general is not a
stable interface. We can certainly work through contents
issues as need be.
b, 10.2 exposes password values and contains primary
administrator. I presume this is out of date.
Assigning values to listed smf properties was intended as an example
of how smf properties could be configured, I will clarify that.
When recently updating the doc, I have overlooked that this still uses
'Primary Administrator'. Thank you for catching this. I will change that
to something else (e.g. System Administrator).
We've talked about how to use pam_chauthtok() to do
password qualification and hashing. I've convinced
myself that this should be straight forward if the
installer can take the hash from a file written to
a specified path.
I believe that this should be fine for interactive installers.
In case of Automated Installer, user is responsible for constructing
password hash and supply it via System Configuration profile.
I assume that today people just use passwd(1) and then copy paste
hashes from shadow(4) to System Configuration profile.
The hard part is to present the
user with a conversation if this is a GUI rather than
a tty based interaction.
Yep, I agree. That's more challenging part :-)
In c, page 7 groupings:users I believe the same applies
unless passwd(1) can be used.
I am not quite sure what you mean. Could you please elaborate
more on that ?
And I thought that the initial
user and root passwords were to be the same, root a role,
and the initial user granted the root role. The root password
would be expired (passwd -r files -f root).
This is definitely the intent in case of interactive installers,
we plan to consolidate that for GUI and text installer by S11FCS.
As far as AI is concerned, admin is currently provided with full control
over how post-install configuration of user and root account is going to
look like.
Is this something which should be reconsidered ?
> 6.2 root account
> ----------------
> For root account, smf unconfigure method will
>
> * remove password hash from shadow(4) file
> (replace it with empty string)
>
> * change root to normal account if it was configured
> asa role.
6.2 passwd -r files -d root should be used to delete the
root password. userattr type root will print role to
stdout if root is of type role and exit 0, nothing and exit 1 if
type is not an attribute of root.
rolemod -K type=normal root will change root to a normal login
account.
Thank you for those suggestions, I was neither aware of 'passwd -r files -d'
nor about 'userattr type root'. That indeed helps.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
