Mike Gerdts wrote: > First off, "Secure by Default" is a great project. I hope to see it > backported to 10.
Thanks. The backport to Solaris 10 is underway as we speak. > > === stdout vs. stderr === > > As I was looking over netservices.sh, I saw some occassions where > error messages seem to find their way to stdout rather than stderr. > > http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/svc/shell/netservices.sh#61 > > > > 61 if svcprop -qp $group $fmri; then :; else > 62 if svccfg -s $fmri addpg $group application; then :; else > 63 echo "Failed to create property group \"$group\" \c" > 64 echo "for $fmri." > 65 exit 1 > 66 fi > 67 fi > 68 > 69 if svccfg -s $fmri setprop $group/$prop = boolean: $val; > then :; else > 70 echo "Failed to set property $group/$prop for $fmri" > 71 exit 1 > 72 fi > > It seems as though the echo statements should be redirected to stderr. Yes, that looks like a bug. > > === y vs. Y vs. yes === > > At > http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/svc/shell/netservices.sh#300 > > > people that have been burned too many times by OpenSSH insisting on > "yes" rather than "y" may be in the habit of typing a few extra > letters. How about the following instead. > > case "$r" in > y*|Y*) > # Make sure we survive killing dtlogin... > trap "" 15 > svcadm restart $DTLOGIN_FMRI > echo "restarting dtlogin" > ;; > *) > printf "dtlogin not restarted. " > printf "Restart it to put it in ${keyword}-mode.\n" > ;; > esac That's a good suggestion, though the problem is mitigated somewhat by the fact that an empty response defaults to yes. I'd want to add the empty string to the yes case above in order to preserve that behavior. > > === localization === > > I notice that netservices(1M) is not localized. Is this a miss or > does it fall into a category that doesn't require localization? It's an administrative command and therefore doesn't necessarily require localization. > > === fallback and dry run === > > It seems like netservices(1M) is a loaded gun pointed at many/most > admin's feet. There may be resistence to using it to lock things down > because there is fear about exactly what it will "break". Without a > dry run feature, people will not necessarily have any idea what it > will change. Without an undo feature, admins may go from customized > (by admin A) closed (by admin B that didn't know what A did) to > wide-open because B broke something and no one knows what customized > state A had previously had the system in. > > Would it make sense to perform a "svccfg extract" or similar prior to > altering the current state to help in the undo at a minimum? Using svccfg extract to back up the current configuration is a good idea and probably something we should recommend in the documentation. I'm a little reluctant to build it into netservices itself, partly because netservices is intended to go away sometime in the future when it is possible to include property settings in a profile. At that point, applying the limited_net profile, including the ability to undo the action, would use nothing but standard SMF commands. > > > Again, very good stuff. > > Mike > Thanks a lot for the feedback. Scott
