First off, "Secure by Default" is a great project.  I hope to see it
backported to 10.

=== 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.

=== 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

=== 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?

=== 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?


Again, very good stuff.

Mike

-- 
Mike Gerdts
http://mgerdts.blogspot.com/

Reply via email to