On 03/19/10 04:58 AM, Mike Gerdts wrote: > On Thu, Mar 18, 2010 at 5:42 AM, Jan Damborsky<Jan.Damborsky at sun.com> > wrote: >> Hi everyone, >> >> please review design specification v0.1 for System Configuration >> SMF Service [2]. >> >> Please provide your comments/feedback before COB Wednesday 3/24. >> >> Darren, Gary, since it seems there might be a security aspect >> of this proposal (see Chapter 10 of design spec), I thought >> you might provide us with valuable feedback which would help >> us to assure that we don't miss anything important as well as >> that we are not unreasonably paranoid. >> If you happen to have cycles to take a quick look, it would >> be greatly appreciated. > > This proposal calls out a long-standing missing feature from the > Solaris passwd(1) or usermod(1M) command. Rather than directly > editing the shadow file, could effort instead be applied to mimic the > Linux "usermod -p $hashed_pw"? Arguably it would be best if it read > the hash from stdin rather than having it on the command line to keep > the password hash private. > > Way too often I've seen expect scripts developed to set passwords. The > expect scripts and their arguments tend to be run through tools like > BladeLogic or Opsware which may not do a good job of protecting the > plaintext password that is being fed to the expect script. I don't > trust most people that would choose to use this method to handle the > failure modes that could exist with a script that edits the shadow > file directly. A fairly simple addition to usermod could satisfy the > needs of this case and very common system administration tasks as > well.
Hi Mike, you are right, consuming API which would modify shadow(4) according to installer needs would be definitely better than modifying that file directly. I have found that there is actually RFE which tracks that desire: 1265957 *usermod* give usermod the ability to add an encypted passwd string http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=1265957 I have added your comments to that bug and raised the priority, since the installer would definitely take advantage of this RFE. I will refer to that bug in the proposal as well. Thank you for pointing this out, Jan
