3.3.1 questions & complaints

Thomas Mitchell mitch at sgi.com
Sat Oct 27 11:20:15 AEST 1990


In article <1990Oct22.233456.4861 at odin.corp.sgi.com> mitch at sgi.com (Thomas Mitchell) writes:
* In article <1990Sep27.192121.18059 at odin.corp.sgi.com> jweldon at sgi.com (Jack P. Weldon) writes:
* * In article <1990Sep26.174852.1344 at ux1.cso.uiuc.edu> wsherman at newton.ncsa.uiuc.edu (William Sherman -Visualization) writes:
* 
* * >..... some shell scripts
*              ^SUID
* 
* * In 3.3, there is a flag to allow suid shell scripts which is shipped
* * "off" for security reasons.

I said: better to not use it and,

* Better to write a 'c' program and make it SUID.  It can
* (should) be very simple.  Just issue a "system()" call to do
* exactly what you wish no more no less.  Do read the  book
* "UNIX System Security"   by Patrick H. Wood and Stephen G. Kochan
* Hayden Book Company   ISBN 0-8104-6267-2
 
Yes, good book, share a copy with a friend.
 
* Of course if you are the only user and not on a network
* turn the bit off in the kernel as above.  Shell scripts
* are much shorter than 'c' programs.

A number of kind people sent me notes regarding this.

Some correctly felt I should have pointed users at execv()
first and not system().  One of the reasons for not using
the system() call "is related to the principle of least
astonishment: the less programs invoked, the better.
system() allows too many security holes to open because it
invokes a shell".  KNOWING that a sh'ell is invoked is key
here.

I elected to use the system() call because the way
I intended to use it.   It provided me with a much better
solution than opening the barn door and turning on
the kernel bit.

I should note: Most carefully crafted programs use execv().

It is very important to know your neighborhood.  Those who
live on or very near the internet need assess their needs
and act accordingly.

Those not on the internet also need to be aware of their
environment.  Perhaps the best example was a person I worked
with who had a timed problem.  His system time kept getting
reset wrong by 5 hours.  Well it turned out his 'network'
spanned 5 timezones.  The individual did not know it
left the building -- let alone the continent.  A short, looong
distance call to the manager of the other system cleared
things up.

Thanks,
mitch

--
--
  Thomas P. Mitchell   --  mitch at sgi.com  or mitch%relay.csd at sgi.com
	"All things in moderation; including moderation."



More information about the Comp.sys.sgi mailing list